/testing
To write thorough, isolated, idempotent tests — 80%+ coverage, external-only mocking, scenario-driven.
$ npx -y skills add griddynamics/rosetta --skill testing --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/testing
Context preview
The summary Claude sees to decide when to auto-load this skill.
To write thorough, isolated, idempotent tests — 80%+ coverage, external-only mocking, scenario-driven.
SKILL.md
testing.SKILL.mdname: testing
description: "To write thorough, isolated, idempotent tests — 80%+ coverage, external-only mocking, scenario-driven."
<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
- CLI testing harness for libraries/packages: commands outputting intermediate results
</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
- Use CLI harness for library testing: execute commands, 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>
Read more
name: testing description: "To write thorough, isolated, idempotent tests — 80%+ coverage, external-only mocking, scenario-driven."
<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
- CLI testing harness for libraries/packages: commands outputting intermediate results
</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
- Use CLI harness for library testing: execute commands, 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>
Repo: griddynamics/rosetta
Other skills on rosetta.
- /collect-github-stats
Collect GitHub repo health/usage stats into merged JSON.
Open skill - /compress-prompt
Compress a Rosetta KB prompt artifact (skill · workflow · phase · rule · agent · template · generic) by stripping structural tautology and ineffective scaffolding while preserving every importance-bearing token. Use when the user asks to compress, shorten, tighten, densify, or
Open skill - /documentation
To write, design, review, simplify, restructure, or standardize OSS project documentation
Open skill - /merge-main
To merge main branch, exact context and instructions
Open skill - /sync-web-site
To synchronize web site with changes made to local *.md files
Open skill - /update-change-log
To synchronize CHANGELOG.md with changes made last week (mon - sun)
Open skill

