surgical-tdd

surgical-tdd

Targeted test execution for repos where a full suite takes 10+ minutes. Iterate with pinpoint tests while editing the code; let CI handle broad regression. Pairs with the regression-probe workflow: write the test first, watch it fail in isolation, watch it flip green when the fix lands.

Not a strict TDD framework — the "TDD" in the name refers to the red-green probe loop for reported bugs, not a write-test-first-for-all-code discipline.

When to use

TRIGGER when: Python monolith with 500+ tests; local full-suite runs >2 min; debugging a specific failure or implementing a feature that touches a narrow surface; writing a regression probe for a reported bug.

SKIP for: small repos where the full suite is <30 s (no time saved); first-contribution exploration of an unfamiliar test layout (broader runs teach you the shape); flaky-test triage (surgical runs hide intermittent failures that only appear under parallel contention).

Pattern

1. Verify the exact target before running

Never guess a test name from memory. Grep the source first:

rg "class ShortcutTest\b" path/to/app/tests/
rg "def test_upgrade_pro_to_enterprise\b"

If the target doesn't match anything, the runner happily reports 0 tests collected as a success — silent false green.

✅ DO: Confirm exact class + method name with rg (or grep -rn) before running. ❌ DON'T: Type a test path from memory; a typo passes silently and wastes container spin-up.

2. Run with a fully-qualified target, not a directory

The finer the scope, the tighter the feedback loop.

Django test runner:

make test ARGS="billing.tests.test_models.BillingPlanTest.test_upgrade_pro_to_enterprise"
# or without a Makefile:
python manage.py test billing.tests.test_models.BillingPlanTest.test_upgrade_pro_to_enterprise

Plain pytest (nodeid or keyword):

pytest path/to/app/tests/test_models.py::BillingPlanTest::test_upgrade_pro_to_enterprise
pytest -k "upgrade_pro_to_enterprise"