Testing strategy
Skill ZC0325/sol-native-guardrails/plugins/sol-native-guardrails/skills/testing-strategy
Five narrowly scoped Codex engineering skills that preserve native model judgment.
npx -y skills add ZC0325/sol-native-guardrails --skill testing-strategyAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 25 days oldThe repository was created 25 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Choose proportionate tests when the validation approach is a material engineering decision, such as critical behavior, regressions, weak or expensive test harnesses, cross-system integrations, or meaningful tradeoffs between strict test-first, targeted automation, and visual or manual evidence. Do not use for routine changes with an obvious existing test path.
SKILL.md
2.3 KB, 346 tokens by cl100k_base, as published. Nobody here has run it
Testing Strategy
Match test rigor to failure cost, uncertainty, and blast radius. Verification is required; one testing ritual is not.
Select A Mode
Strict test-first
Prefer a failing test before implementation for reproducible regressions, security or permission logic, financial or data-integrity rules, stable algorithms, and public behavior contracts. Confirm that the test fails for the intended reason.
Test-first preferred
Use for new APIs, reusable business logic, component interactions, and refactoring with a usable test harness. Small exploratory spikes may precede the durable implementation, but discard or isolate them before relying on the test suite.
Implement then verify
Allow for low-risk integration glue, localized configuration, generated artifacts, migrations, legacy areas without a practical harness, and changes where a failing test would add disproportionate setup cost. Add targeted regression coverage when the behavior is important enough to preserve.
Visual or manual validation
Use rendering, screenshots, interaction checks, or focused inspection for styling and visual artifacts. Add automated checks where stable assertions are meaningful.
Verification
Run the smallest command that directly proves the changed behavior, then broaden checks according to shared contracts and blast radius. Record the actual result. If a relevant check cannot run, explain why and identify the next best evidence.
Boundaries
- Do not delete valid implementation solely because its test was written later.
- Do not maximize test count; cover behavior, failure modes, and important contracts.
- Prefer real behavior over mock choreography unless isolation is necessary.
- Do not treat linting as proof that code builds or behavior works.
- Do not require strict TDD for documentation, trivial metadata, or purely cosmetic edits without a stable automated assertion.