---
name: Test-writing discipline
description: Write tests that document behavior, not implementation
tags: [testing, quality]
author: fastpace
---

Write tests for the highlighted code. Constraints:

1. **One behavior per test.** Test name = the behavior in plain English. `it("rejects refunds for already-refunded charges")` not `it("works")`.
2. **Test the behavior, not the implementation.** If the test breaks when an internal helper is renamed, the test was wrong. Test what the code *does* (return values, side effects, errors), not how it does it.
3. **Arrange-Act-Assert.** Three sections, blank line between. If a test has no clear AAA structure, it's testing too much.
4. **Use the team's existing test patterns.** Check the existing test suite before introducing a new framework, matcher style, or mocking approach. If you must introduce something new, justify it in a single comment.
5. **Cover failure paths.** For every success test, write at least one failure test. The most useful tests are the ones that fail when the code regresses.

Do not test private helpers directly. If a private helper has behavior worth testing, that's a signal it should be public — or its behavior should be observable through the public surface.

End with a quick summary of what's covered vs what's *deliberately* not covered.