Test-Driven Development.

Drive the design and verify the correctness of code by writing a failing test for each small piece of behavior before writing the code that satisfies it, then improving the design while the tests keep you safe.

Code written without tests is risky to change: there is no quick way to know whether an edit broke something. Tests written after the fact tend to be shallow, shaped to fit code that may already be hard to test, and they rarely influence the design.

Without a forcing function, designs also tend to grow tangled and hard to exercise in isolation.

Work in a short Red-Green-Refactor cycle:

1. Red — write a small test for the next bit of behavior and watch it fail.
2. Green — write the simplest code that makes the test pass, even if it is ugly.
3. Refactor — clean up the code (and the tests) now that they are green, with the suite guarding against regressions.

Repeat in minutes-long loops. Because tests come first, the code is testable by construction and the suite documents the intended behavior.

• The cycle — Red → Green → Refactor, repeated continuously.
• Test list — the running list of behaviors still to cover.
• Arrange–Act–Assert — the shape of a focused unit test.
• Unit under test — the small slice of behavior each test pins down.

• Use it for code with real logic and branching, and for long-lived code that will change often.
• Especially valuable where a fast feedback loop and regression safety matter.
• Less suited to throwaway spikes or exploratory UI work where the design is still in flux.

1. Pick the next small behavior from your test list.
2. Write a test that asserts it, and run the suite to see it fail (red).
3. Write the minimum code needed to pass; run the suite (green).
4. Refactor production and test code while keeping the suite green.
5. Repeat, adding behaviors to the list as you discover them.