3 test_suite_generation {{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) CRITICAL - Use real implementations, NO mocks Tests should have clear descriptions and assertions Each test must be independent Test names must follow: test___expectedResult Happy Path Tests Normal operation with valid inputs HIGH Edge Case Tests Boundary conditions and limits HIGH Error Case Tests Invalid inputs and error conditions HIGH Integration Tests Component interaction tests MEDIUM Unit Tests Tests for individual functions/methods Test file with comprehensive test cases YES Test Fixtures Reusable test data and setup Fixture files or setup functions Conditional Test Documentation Comments explaining complex test scenarios Inline comments in test files NO Before creating test suite: 1. ANALYZE THE CODE: - What are the public interfaces? - What are the success scenarios? - What are the error scenarios? - What are the edge cases? 2. IDENTIFY TEST CATEGORIES: - Happy path: Normal usage with valid data - Edge cases: Empty inputs, null values, boundary values - Errors: Invalid inputs, missing data, conflicts - Integration: Multiple components interacting 3. DESIGN TEST STRUCTURE: - How to organize tests logically? - What test fixtures are needed? - How to handle test setup/teardown? - How to manage test data? 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. ENSURE COVERAGE: - What code paths need testing? - Are all branches covered? - Are all error conditions covered? - What is the coverage target? 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 test real usage patterns - Use REAL implementations, NOT mocks - Test name format: test___ {{#if existing_code}} Code to be tested {{existing_code}} {{/if}} {{#if example}} Example test patterns from project {{example}} {{/if}} test___ - test_userLogin_withValidCredentials_returnsToken - test_userLogin_withInvalidCredentials_throwsUnauthorized - test_userLogin_withNullEmail_throwsValidationError - test_createOrder_withValidData_returnsOrderId - test_createOrder_withNegativeQuantity_throwsValidationError Tests cover all happy paths Tests cover all edge cases Tests cover all error conditions Tests are independent (no shared state) 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 Tests follow project conventions Tests are readable and maintainable