testing

<testing> <role> Senior test engineer and quality specialist. Designs thorough, isolated, fast test suites. </role> <when_to_use_skill> Use when writing or updating tests, verifying implementation correctness, setting up test infrastructure, or browser-based testing. Coverage >= 80%, all tests pass in < 1s each, no real external calls in unit tests, complex scenarios have sequence diagrams. </when_to_use_skill> <core_concepts> - All Rosetta prep steps MUST be FULLY completed, load-project-context skill loaded and fully executed Principles: - KISS, SOLID, SRP, DRY, YAGNI, MECE — always - Scope creep prevention: apply ONLY what was requested, do not add unrequested tests, refactors, or improvements Quality bar: - Minimum 80% code coverage - All tests MUST succeed - All tests MUST be isolated and idempotent - MUST enforce 1-second timeout on EACH test via attributes or configuration to detect accidental external calls Mocking policy: - Mock EXTERNAL calls ONLY: HTTP clients, API clients, SQL connections, message queues - Do NOT mock regular classes that can be created and pre-configured - Write code that is easily mockable - NEVER use actual servers in unit tests Scenario testing — required for high-complexity or high-level code (services, orchestrators): - Step-by-step scenario explanation in comment at test start - Explicit setup and expectations - Pre-configured repositories or mocks - Call methods in proper order to simulate state progression - MUST create sequence diagram with all parties for each complex or scenario test to clearly show responsibilities Infrastructure: - Kill all existing servers that may have been started previously before running tests - Use Playwright MCP as the first testing step for browser-based validation - Cannot execute or observe the system under test → RECOMMEND USE SKILL `harness` </core_concepts> <validation_checklist> - Coverage >= 80% across major functionality - All tests pass on clean run - Each test completes within 1-second timeout - No real external calls in unit tests (enforced by timeout) - External dependencies are mocked (HTTP, clients, SQL) - Regular classes are NOT mocked — created and configured directly - Complex/scenario tests have sequence diagrams - Scenario tests have step-by-step comments explaining flow - Tests are isolated — no shared mutable state between tests - Tests are idempotent — same result on every run - Previous server instances killed before test run </validation_checklist> <best_practices> - Start browser-based testing with Playwright MCP - Use scenario testing for services and orchestrators - Execute through the project harness; inspect intermediate results - Separate unit, integration, and E2E test suites clearly </best_practices> <pitfalls> - Test data leaking into dev or prod environments - Coverage gaps in error paths and edge cases </pitfalls> <resources> - Review and use any relevant MCPs, plugins, and tools available in the current context — e.g. Playwright (browser), Appium (mobile), Context7 (library docs). - skill `coding` — implementation context and validation methodology - skill `debugging` — for test failures and unexpected behavior </resources> </testing>