Test-Driven Development Rules

tddtestingbest-practices

Enforces TDD workflow including Red-Green-Refactor cycle, test design principles, naming conventions, and the discipline of writing tests before implementation code.

Целевые файлы

Файл	Формат
.cursorrules	plaintext
CLAUDE.md	markdown

Содержимое

## Test-Driven Development Rules ### The Red-Green-Refactor Cycle - Write a failing test FIRST — this is the definition of "red" - Write the MINIMUM code required to make the test pass — this is "green" - Refactor the implementation and tests while keeping all tests green — this is "refactor" - Never write production code without a failing test driving it - If a test passes immediately after writing it, the test is wrong or the code already handles it - One failing test at a time — do not write a batch of failing tests before making them pass ### Test Design - Each test must verify exactly one behavior — if the test name requires "and", split it - Tests are the living documentation of the system — they must be readable without comments - Use the Arrange-Act-Assert (AAA) structure: set up, perform action, check result - Each section (Arrange, Act, Assert) separated by a blank line for visual clarity - Never have multiple assertions that test different behaviors — one concept per test - Tests must be independent — no test should depend on the state left by another test ### Test Naming - Test names must describe behavior, not implementation: `should_return_404_when_user_not_found` not `testGetUser` - Use the pattern: `[unit]_[scenario]_[expected outcome]` - Negative tests are as important as positive ones: `should_reject_invalid_email` - Use descriptive names for test data: `validAdminUser`, `expiredToken`, `emptyShoppingCart` ### Test Doubles - Use stubs to provide indirect inputs (canned responses from dependencies) - Use mocks to verify indirect outputs (interactions with dependencies) - Use fakes for lightweight in-memory implementations (in-memory repository) - Use spies only when you need to verify that a method was called with specific arguments - Prefer dependency injection to enable test doubles — avoid hard-coded dependencies - Do not mock the class under test — mock its collaborators ### Unit Tests - Unit tests must be fast — under 100ms per test; a full suite should run in seconds - Unit tests must be isolated — no network calls, no file system access, no database queries - A unit test tests a single unit of behavior, not a single function — the unit is a behavior cluster - If a unit test requires dozens of lines of setup, the class under test is too complex (SRP violation) ### Integration Tests - Integration tests verify that modules work together correctly (e.g., service + real database) - Use a real (or containerized) database for integration tests — not mocks - Reset state between integration test runs — use transactions that roll back or test containers - Integration tests are slower; run them separately from the unit test suite in CI ### Coverage & Quality - Code coverage is a floor, not a target — 100% coverage does not mean the tests are good - Mutation testing reveals test quality — if a mutant survives, the test suite is incomplete - Test all branches: happy path, error paths, boundary conditions, null/empty inputs - Delete tests that do not fail when the behavior they claim to test is broken ### Refactoring Under TDD - Refactor only when all tests are green — never refactor and change behavior simultaneously - Extract methods, rename variables, remove duplication — all while keeping tests green - If refactoring breaks a test, stop: either the refactoring changed behavior (wrong) or the test is too tightly coupled to implementation (fix the test) - Tests must also be refactored for clarity — messy tests become a maintenance burden ### TDD Discipline - Commit at green — never commit failing tests to main/master - If the TDD cycle takes more than 15 minutes, the scope is too large — break the task down - Spike solutions (exploratory coding without TDD) are acceptable; delete spikes, then TDD the solution - Legacy code: add a characterization test before refactoring any untested code ### Anti-patterns - Writing tests after implementation defeats the design benefits of TDD - Testing private methods — test behavior through the public API; private methods are implementation detail - Overspecified tests that know too much about internals — they break on refactoring - Tests that always pass — they give false confidence and hide regressions

CLI

npx mindaxis apply tdd-rules --target cursor --scope project

Используется в паках

QA Automation

Test automation and quality assurance

Открыть пак →

TDD Workflow

Red-green-refactor from day one

Открыть пак →

← Правила

Test-Driven Development Rules

tddtestingbest-practices

Enforces TDD workflow including Red-Green-Refactor cycle, test design principles, naming conventions, and the discipline of writing tests before implementation code.

Целевые файлы

Файл	Формат
.cursorrules	plaintext
CLAUDE.md	markdown

Содержимое

CLI

npx mindaxis apply tdd-rules --target cursor --scope project

Используется в паках

QA Automation

Test automation and quality assurance

Открыть пак →

TDD Workflow

Red-green-refactor from day one

Открыть пак →