agentleFS
jhutchison0jhutchison0/tacsop/.claude/skills/shift-left-testing/SKILL.md

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

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
  1. Distinctive:

    Test independence: Every test runs in isolation.

    line 27
  2. Distinctive:

    Mock external dependencies: Never let tests depend on APIs, databases, hardware, or other services you don't fully control.

    line 28
  3. Very specific:

    Test early, test often: Write tests before or alongside code, never after.

    line 29
  4. Very specific:

    Test files: test_*.py or *_test.py

    line 75

“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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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:

  1. Test independence. Every test runs in isolation. No shared mutable state between tests, no execution-order dependencies.
  2. Mock external dependencies. Never let tests depend on APIs, databases, hardware, or other services you don't fully control.
  3. 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.
  4. 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

TierSpeedScopeDependenciesShare of total
Unit<1sSingle componentMocked60–70%
Integration1–10sComponent interactionSome real, some mocked20–30%
System10–60sEnd-to-endReal or simulated5–10%
External>60sWith real external systemsReal APIs/hardwareOptional

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_*.py or *_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.py tripwire plugin (deletion, network, dotenv), registered through addopts, 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

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.