standr/testing
Test confidence
AI-generated tests go green. The problem is what they fail to buy: confidence. Too many mocks, happy-path only, brittle setup, overfit to implementation. Green CI, low trust. The testing skill turns a passing suite into one you can actually trust.
9 skills
Diagnostic
/testing-scan Diagnose why a suite passes but still does not buy confidence.
/testing-review Final quality pass: would this test catch a real break?
Structure
/testing-fixtures Replace inline test data with shared, composable fixtures that tests can reuse.
/testing-mocks Choose what to mock, stub, or keep real.
/testing-determinism Eliminate clocks, randomness, and shared state that make tests pass sometimes and fail others.
Coverage
/testing-scope Decide what belongs in unit, integration, or end-to-end scope.
/testing-invariants Add behavioral guarantees and edge cases the suite is missing.
/testing-contract Protect public API, schema, and boundary behavior instead of implementation details.
/testing-regression Turn bugs and incidents into durable tests.
Demo
The diff
Same test suite, same assertions. The left side is what passes CI but breaks in production. The right side is what actually buys confidence.
Use whenever a test asserts that a mock was called rather than that the system behaved correctly. It replaces internal assertions with observable behavior: HTTP status codes, response shapes, and persisted state. `assert_called_once_with(payload)` passes even when the endpoint returns 500 and serializes nothing — the contract test fails when what actually matters to the caller fails.
The caller depends on status codes and response shape — not on which internal method was called.
Install
$ npx skills add https://gitlab.com/standr.dev/standr $ claude plugin marketplace add https://gitlab.com/standr.dev/standr.git
$ claude plugin install architecture@standr
$ claude plugin install refactor@standr
$ claude plugin install testing@standr $ git clone https://gitlab.com/standr.dev/standr.git