3 test_creation {{task}} {{context}} {{#each requirements}} {{this}} {{/each}} {{allowed_libraries}} {{forbidden_approaches}} {{test_coverage_minimum}} {{integration_requirements}} Use project's existing test framework (detected via /testing:prime) DO NOT mock services - use real implementations Tests should be verbose for debugging Each test should be independent Test names should clearly describe what is being tested Unit Tests Tests for individual functions/methods Test file matching project structure YES Integration Tests Tests for component interactions Test file in integration test directory Conditional Edge Case Tests Tests for boundary conditions and errors Included in unit tests YES Test Documentation Comments explaining complex test scenarios Inline comments NO Before creating tests: 1. ANALYZE THE CODE: - What are the entry points (functions, methods, endpoints)? - What are the success scenarios? - What are the failure scenarios? - What are the edge cases? 2. IDENTIFY TEST CATEGORIES: - Happy path tests (normal operation) - Edge case tests (boundaries, limits) - Error case tests (exceptions, invalid input) - Integration tests (if multiple components) 3. DESIGN TEST STRUCTURE: - How to organize tests logically? - What test fixtures/setup is needed? - How to handle test data? - How to clean up after tests? 4. PLAN ASSERTIONS: - What exactly should be verified? - How to assert on results? - How to assert on side effects? - How to assert on errors? 5. CONSIDER COVERAGE: - What code paths need testing? - Are all branches covered? - Are all error conditions covered? - What is the target coverage percentage? CRITICAL TESTING PRINCIPLES: - Tests must be independent (no shared state) - Tests must be repeatable (same result every time) - Tests must be verbose (clear failure messages) - Tests must be realistic (test actual usage patterns) - Use real implementations, NOT mocks {{#if existing_code}} Code to be tested {{existing_code}} {{/if}} {{#if example}} Example test pattern from codebase {{example}} {{/if}} Arrange-Act-Assert 1. Arrange: Set up test data and conditions 2. Act: Execute the code being tested 3. Assert: Verify expected outcomes Given-When-Then 1. Given: Preconditions and context 2. When: Action is performed 3. Then: Expected outcome Test Naming Use descriptive names like: - test_userAuthentication_withValidCredentials_returnsToken - test_calculateTotal_withNegativeInput_throwsException Tests cover all code paths Tests include edge cases Tests include error conditions Tests are independent Tests use real implementations (no mocks) Tests have clear, descriptive names Tests have helpful failure messages Tests clean up after themselves Test coverage meets minimum threshold Tests run quickly