Walkthrough

Spec → Tests → Code

Front-load tests; let the agent fill them in. Why this beats spec → code → tests.

When the spec exists as failing tests *first*, the agent has a measurable target. It writes code, runs tests, sees red, edits, runs again. The loop terminates only when the spec is satisfied.

When you write code first and tests after, the tests describe what the code already does — not what it should do. They lose their value as a forcing function.

Steps · 0 / 3 done

Describe the spec in prose
Don't dive into types yet. Write 4-6 sentences that describe the behavior, the inputs, the outputs, the edge cases.
```
Write a function `parseDuration` that takes strings like '5m', '1h30m', '2d4h' and returns total minutes. Throws on empty input. Ignores whitespace. Case-insensitive units.
```
VerifyThe spec is short, behavior-focused, and lists at least 2 edge cases.
Have the agent write tests first
Ask explicitly for tests before any implementation.
```
Before writing parseDuration, write a Vitest file that asserts the spec. Include the edge cases. Run it — every test should fail.
```
VerifyYou see a test file and a failing run with N failures, where N matches the assertions.
Now write the code
Ask for the implementation. Iterate until green.
```
Now implement parseDuration to make every test pass. Don't stop until the run is green.
```
VerifyTests pass. Code is shaped by the spec, not by the first thing that came to mind.

Check your understanding

Q1. Why are tests written *before* the implementation more valuable than tests written after?

· Tick off the 3 step(s) above.

· Score 100% on the quiz.

Spec → Tests → Code

Describe the spec in prose

Have the agent write tests first

Now write the code