Tdd Change

TDD Change

Instructions

1. Identify the smallest observable behavior covered by the approved spec.
2. Add or update one focused failing test or golden fixture before changing behavior code.
3. Run the narrowest relevant test command and confirm RED: the test fails for the expected reason, not because of a typo, setup error, or unrelated failure.
4. Implement the smallest change that satisfies the failing test and the spec.
5. Run the same focused test command and confirm GREEN: the test passes without new warnings or unrelated failures.
6. Refactor only after GREEN, then rerun the focused test command.
7. Do not update golden files only to hide an unexplained behavior change.

Testing Anti-Patterns

• Do not write a tautological test: expected values must come from an independent source, never recomputed the way the code under test computes them.
• Do not assert on mock elements or mock call counts when a real behavior assertion is possible.
• Do not add production methods, flags, or exports that exist only for tests.
• Do not mock a dependency until you understand the side effects the test needs.
• Keep test doubles structurally complete enough to match the real data shape consumed by the code.
• If mock setup is larger than the behavior under test, consider a narrower integration test or a simpler production boundary.

Mock Boundary

• Mock only unmanaged external dependencies, such as network, clock, or filesystem you do not own.
• Prefer a fake over a stub, and a stub over a mock or spy.
• Use a spy only where outbound communication is itself the tested contract.
• Never introduce an abstraction that exists only for a test.

Seam Discipline

• Read CONTEXT.md when it exists; test names and interface names must match its glossary terms.
• Test only at the seam declared in the issue brief; do not re-decide the seam inside the loop.
• If implementation shows the declared seam is wrong, stop and report BLOCKED with the reason. Never silently move or redesign the seam.

Output

Report the RED command and expected failure, the GREEN command and passing result, any refactor rerun, and any TDD exception that required human approval.

Safety

• Do not install dependencies automatically.
• Do not run broad or destructive commands without explicit approval.
• Do not include secrets, environment variable values, or production endpoints in tests or fixtures.