Sin #1 — Putting Off Testing Until the End

easy

Learn with your AI

Open this lesson in your favourite AI. It'll walk you through the why, explain the demo, and quiz you on the try-it list.

Open in Claude Open in ChatGPT

Why this matters

Cohen calls late testing the vice of laziness because it is genuinely tempting: testing early is uncomfortable. The PCB isn't done yet; the API isn't stable; we don't have real users; we'll test 'when we have something to test.' By the time you have something to test, the cost of a major finding is 10-100x what it would have been if you'd built tests alongside the prototype. The discipline is to wire up testing infrastructure — even crude testing — in week 1, not week 30.

Demo

What testing-early actually means.

Try it yourself

On your current project, identify one subsystem that has zero tests today.
Estimate: cost of writing a test for it now vs. waiting until launch week.
Identify the cheapest test you could write in the next 30 minutes that would catch the most common failure.
Write that test. (Whether it's a Python script poking your hardware or an integration test hitting your API.)

Prompt your AI

Use these three in order. Each builds on the one before.

1. Basics & terminology

Explain in one paragraph why testing-late costs 10-100x more than testing-early.

2. Why it works (the mechanism)

Walk me through what 'testing alongside design' looks like in week 1, week 10, and week 30 of a hardware project.

3. Advanced — application & what's next

Given a startup with a working 0.1 prototype and 6 months to launch, design a testing roadmap that grows in lock-step with the product.

References

HARDWARE TRACK:

WEEK 1 PROTOTYPE (looks like a breadboard mess):
  Test setup that already exists:
    - Bench multimeter + scope hooked up to power rails.
    - Logic analyzer ready for SPI/I2C.
    - Photo log of each board revision.
    - Simple Python script: "send command, expect response, log".

  This is a TEST INFRASTRUCTURE for the prototype itself.
  Cost: ~$300 in tools + 2 hours setup.

WEEK 30 PRODUCT (looks like a real device):
  Test setup needed:
    - HIL (hardware-in-the-loop) rig: $50k.
    - Compliance pre-scan chamber: $1500/day rental.
    - Drop tester, thermal chamber: factory access.
    - End-of-line test fixture: $10-30k.

  Cost: 100x the prototype rig.

THE INSIGHT:
  Each week, the test rig "should" grow alongside the product.
  Cohen's principle: testing infrastructure tracks design complexity.

  Every new subsystem gets a test the same week it's added.

SOFTWARE ANALOGUE:

WEEK 1 PROTOTYPE (a single endpoint, some seed data):
  Test setup that already exists:
    - One unit test that exercises the happy path.
    - One integration test that hits the endpoint.
    - CI runs on every PR.
    - Logs are structured (JSON) from day 1.

  Cost: ~30 min setup. Free tools.

WEEK 30 PRODUCT (multi-service backend, 100s of endpoints):
  Test setup needed:
    - Contract tests between services.
    - Load test rig.
    - Chaos test scenarios.
    - End-to-end suite.
    - Synthetic prober in prod.

  Cost: weeks of work. Often retrofit.

THE PARALLEL:
  In software, the SIN looks like "we'll write tests later."
  Two months in, "later" is now. The codebase has 50 endpoints,
  none tested, all coupled. Adding tests now is a rewrite.

  Better: 1 test per endpoint, written same day the endpoint is.

THE NAMING:
  Cohen calls this the VICE OF LAZINESS.
  Not because testers are lazy.
  Because skipping testing FEELS LIKE progress (more features per sprint)
  while compounding a debt that becomes unpayable.