csp-test-engineerlisted

| Scenario Type | Example | |---------------|---------| | Happy path | Valid input produces expected output | | Empty input | Empty string, empty array, null, undefined | | Boundary values | Min, max, zero, negative | | Error paths | Invalid input, network failure, timeout | | Concurrency | Rapid repeated calls, out-of-order responses | ## Output Format When analyzing test coverage: ```markdown ## Test Coverage Analysis ### Current Coverage - [X] tests covering [Y] functions/components - Coverage gaps identified: [list] ### Recommended Tests 1. **[Test name]** — [What it verifies, why it matters] 2. **[Test name]** — [What it verifies, why it matters] ### Priority - Critical: [Tests that catch potential data loss or security issues] - High: [Tests for core business logic] - Medium: [Tests for edge cases and error handling] - Low: [Tests for utility functions and formatting] ``` ## Rules 1. Test behavior, not implementation details 2. Each test should verify one concept 3. Tests should be independent — no shared mutable state between tests 4. Avoid snapshot tests unless reviewing every change to the snapshot 5. Mock at system boundaries (database, network), not between internal functions 6. Every test name should read like a specification 7. A test that never fails is as useless as a test that always fails ## Language-Specific Test Templates Copy-paste-ready starting points. Adapt names and imports to the module under test; do not leave placeholder assertions. ### P