sota-testinglisted
State-of-the-art software testing strategy and practice (2026) for designing test strategy, writing unit/integration/e2e tests, or auditing test suites. Covers suite shape (pyramid/trophy/honeycomb), test design quality (behavior-first, AAA, determinism, smells), test doubles (mocks/fakes/stubs), test data (builders over fixtures), real-dependency integration (Testcontainers-style), contract testing (Pact/consumer-driven), e2e/UI strategy (selectors, auto-waiting, flake economics), property-based testing, fuzzing, mutation testing, approval testing, and suite health/CI (flaky-test policy, coverage philosophy, sharding). Trigger keywords - testing, test strategy, unit test, integration test, e2e, end-to-end, coverage, flaky tests, TDD, contract testing, property-based, mocking, fixtures, snapshot test, mutation testing, fuzzing, BDD, Gherkin, given-when-then, acceptance criteria, security testing, WSTG, IDOR test, authz test, abuse case, DAST. Use for BOTH building and auditing test suites.
martinholovsky/SOTA-skills · ★ 8 · Testing & QA · score 75
Install: claude install-skill martinholovsky/SOTA-skills
# SOTA Testing (2026)
Expert-level, language-agnostic rules for producing and auditing production test
suites. Per-language runner/tooling details (pytest, go test, cargo test,
vitest/jest) live in the language skills (`sota-python`, `sota-golang`,
`sota-rust`, `sota-javascript-typescript`) — this skill defines the strategy,
design discipline, and quality bar those tools execute against. Every rule
states the *why*; every rules file ends with an audit checklist of yes/no
questions and grep-able smells.
## Purpose
Two consumers, one source of truth:
- **BUILD mode** — designing a test strategy or writing tests for new code:
follow the rules as defaults, not suggestions. Deviate only with an explicit
comment justifying the deviation.
- **AUDIT mode** — reviewing an existing suite: hunt violations using the audit
checklists, classify by severity, report in the finding format below.
## BUILD mode
1. Before writing tests, read the rules files relevant to the layer you are
testing (see index). A service touching HTTP + DB + a message queue needs
`01`, `02`, `03`, `04`.
2. Apply the **top-10 non-negotiables** (below) unconditionally.
3. Decide the suite shape FIRST (`rules/01`): what counts as a unit here, where
the integration boundary is, which 3–10 flows deserve e2e. Write that
decision down (CONTRIBUTING.md or a test README) so the next contributor
doesn't relitigate it.
4. New test code is production code: same review bar, same lint rules, no
`TODO