write-tests

# /write-tests Write failing tests that encode acceptance criteria. ## Usage ``` /write-tests /write-tests Add logout button to header ``` ## When to Use - After creating a todo that requires implementation - Before running `/implement` - When you have clear acceptance criteria ## When NOT to Use - Implementation already exists (tests would pass immediately) - You're exploring or prototyping (not TDD mode) - Just adding to existing test coverage ## What It Does 1. Analyzes the current todo/requirement 2. Reads existing tests to understand patterns 3. Writes test files that verify acceptance criteria 4. **Verifies tests FAIL** (proves they test something real) 5. Returns test file paths for `/implement` ## Output The tester agent will produce: ```markdown ## Tests Written ### Files Created/Modified - `tests/test_client.py` ### Tests Added | Test | Verifies | |------|----------| | `test_client_reset_returns_observation` | Reset returns valid observation | | `test_client_step_advances_state` | Step mutates state correctly | | `test_client_handles_invalid_action` | Error handling for bad input | ### Verification All tests FAIL as expected (no implementation yet). ### Next Step Run `/implement` to make these tests pass. ``` ## Rules 1. **Read existing tests first** to understand patterns and conventions 2. **Test behavior, not implementation** - write from user's perspective 3. **Integration tests first**, then unit tests if needed 4. **Each test verifies ONE thing** clearly 5. **Run tests to verify they fail** before returning ## Anti-patterns (NEVER do these) - Writing tests that pass without implementation - Testing implementation details instead of behavior - Writing overly complex test setups - Adding implementation code (that's `/implement`'s job) - Writing tests that duplicate existing coverage ## Completion Criteria Before returning, verify: 1. Tests compile/run successfully (pytest can collect them) 2. Tests FAIL (no implementation yet) 3. Test names clearly describe what they verify 4. Tests follow existing project patterns (see `tests/` for examples)