shift-left-testing
Skill0 starsChanged 23 days agoApache-2.0View on GitHub
Multi-tier testing strategy with vertical-slicing (tracer-bullet) TDD, mocks, fixtures, simulation, property-based invariants, numeric tolerances, legacy characterization, script/CLI testing, test isolation (deletion, network, and load_dotenv tripwires), CI integration, and explicit anti-patterns. Use when setting up test infrastructure, designing test strategy, implementing mocks, or driving feature work via test-first one-cycle-at-a-time TDD.
3 other projects use a version of this.
Adopted by
Most recently taken up by
- upex-galaxy/agentic-qa-boilerplatetheir own version, first seen Nov 7, 2026
- petrkindlmann/qa-skillstheir own version, first seen Oct 25, 2026
- proffesor-for-testing/agentic-qetheir own version, first seen Oct 25, 2026
Other versions3 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 3
- proffesor-for-testing/agentic-qe★ 524same name
- petrkindlmann/qa-skills★ 209same name
- upex-galaxy/agentic-qa-boilerplate★ 26same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository13 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- configuration-managementSkill
- designing-clear-data-displaysSkill
- lake-conventionsSkill
- maintaining-project-contextSkill
- maintaining-the-common-operating-pictureSkill
- maintaining-ubiquitous-languageSkill
- python-venv-managementSkill
- recording-architecture-decisionsSkill
- traversing-the-knowledge-baseSkill
- using-topic-branchesSkill
- verifying-claimsSkill
- writing-simple-and-directSkill
The file
We split this skill into the rules it gives an agent
4 rules. 0 are common, 2 are distinctive, and 2 are very specific to this project.
0
Common
Most of the 3 edited versions we read keep these.
2
Distinctive
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 27
Test independence: Every test runs in isolation.
- Distinctive: line 28
Mock external dependencies: Never let tests depend on APIs, databases, hardware, or other services you don't fully control.
- Very specific: line 29
Test early, test often: Write tests before or alongside code, never after.
- Very specific: line 75
Test files: test_*.py or *_test.py
“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Shift-Left Testing
Move testing earlier in the development cycle: test components before integration, test with mocks before hardware, test logic before dependencies exist. This SKILL.md is the entry point; deep procedural content lives in sidecar files loaded on demand.
Philosophy: "Never skip tests because dependencies aren't ready. Mock what you don't have, test what you build, validate continuously."
When to Use
- Setting up test infrastructure for a new project or component
- Designing the test strategy for a feature before writing code
- Implementing mocks for external dependencies
- Driving feature work via test-first TDD (the vertical-slicing rhythm)
- Reviewing test coverage, quality, or detecting anti-patterns
- Testing numeric, stochastic, or invariant-bearing code (scorers, pipelines, graph metrics)
- Wrapping legacy code or scripts in tests before changing them
Core Principles
Four rules that govern everything else in this skill:
- Test independence. Every test runs in isolation. No shared mutable state between tests, no execution-order dependencies.
- Mock external dependencies. Never let tests depend on APIs, databases, hardware, or other services you don't fully control.
- Test early, test often. Write tests before or alongside code, never after. Vertical slicing (one test → one implementation → repeat) is the rhythm; see
VERTICAL-SLICING.md. - Fail fast, fail clear. Tests should fail quickly with messages that name what's wrong, not just that something is wrong.
Quick Reference
Test Pyramid
/\
/ \ E2E / External (few, slow, complete system)
/____\
/ \
/ System \ (few, slow, end-to-end)
/__________\
/ \
/ Integration \ (medium quantity, medium speed)
/__________________\
/ \
/ Unit Tests \ (many, fast, isolated)
/______________________\Test Tiers
| Tier | Speed | Scope | Dependencies | Share of total |
| Unit | <1s | Single component | Mocked | 60–70% |
| Integration | 1–10s | Component interaction | Some real, some mocked | 20–30% |
| System | 10–60s | End-to-end | Real or simulated | 5–10% |
| External | >60s | With real external systems | Real APIs/hardware | Optional |
Test Directory Layout
tests/
├── fixtures/ # Shared test data, mock objects
├── golden/ # Golden files for snapshot comparisons (see REGRESSION.md)
├── unit/ # Fast, isolated component tests
├── integration/ # Multi-component interaction tests
├── simulation/ # Digital twin / simulated environment tests
├── scripts/ # Script and CLI tests (see SCRIPTS.md)
└── external/ # Real external system tests (optional)Naming Conventions
- Test files:
test_*.pyor*_test.py - Test functions:
test_* - Test classes:
Test*
Anything else won't be auto-discovered by pytest.
Sidecar Files
Loaded on demand when this SKILL.md cites them. Read only the ones relevant to the task at hand.
- TIERS.md — test pyramid expanded, tier strategy, root-level vs component-level test layouts, decision rule for which to use.
- PATTERNS.md — unit, integration, and simulation testing patterns with worked examples.
- MOCKS.md — three mock patterns: simple, configurable, realistic-with-behavior.
- FIXTURES.md — shared fixtures, conftest patterns, test data management (YAML, Faker, generated).
- VERTICAL-SLICING.md — tracer-bullet TDD discipline: rules, pre-code planning checklist, core principle. Adapted from Pocock.
- PROPERTY-BASED.md — invariant testing with Hypothesis: strategies, monotonicity and round-trip properties, oracle tests, CI settings. Read for scorers, normalizers, parsers, and graph transforms.
- NUMERIC.md — float comparison and tolerance selection, numpy and pandas assertions, injectable randomness, testing stochastic code. Read whenever a test touches computed numbers.
- REGRESSION.md — characterization tests for legacy code and the golden-file workflow (normalization, bless discipline, churn control). Read when the audit hook fires on untested code.
- SCRIPTS.md — testing CLIs and filesystem scripts: thin main, tmp_path repo factories, dry-run contracts, the subprocess tier, and widening the enforcement perimeter to scripts/.
- ISOLATION.md — tests never touch the real world: pass data roots in as parameters, and the
tests/isolation.pytripwire plugin (deletion, network, dotenv), registered throughaddopts, as the backstop, with what it cannot see. - ENFORCEMENT.md — enforcement gradient (probabilistic → deterministic), the PostToolUse audit hook, why we don't hard-block, when to escalate.
- CI.md — GitHub Actions example, coverage thresholds, marker-based test selection.
- ANTIPATTERNS.md — four anti-patterns to avoid, examples by domain (web API, data pipeline, ML), and the pre-commit testing checklist.
References
- Martin Fowler, "The Practical Test Pyramid"
- Kent Beck, Test-Driven Development by Example — foundational TDD pattern
- Matt Pocock,
mattpocock/skills/skills/engineering/tdd/SKILL.md— vertical slicing rules adapted into VERTICAL-SLICING.md - Michael Feathers, Working Effectively with Legacy Code (2004): the characterization discipline in REGRESSION.md
- Hypothesis documentation: property-based testing library used in PROPERTY-BASED.md
- pytest documentation
- numpy.testing and pandas.testing: assertion helpers used in NUMERIC.md
- unittest.mock — Python's built-in mocking
- pytest-cov — coverage plugin
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

