test-driven-development

Write one minimal failing test describing the desired behavior, run it to confirm it fails for the right reason, then write the simplest code to make it pass. Refactor only while tests stay green, then repeat the cycle for the next behavior.

Tests written after code pass immediately, which proves nothing about whether they test the right thing. Watching a test fail first confirms it actually exercises the missing behavior and catches real bugs rather than mirroring the implementation.

Delete the code and start over with a failing test. Keeping it as reference or adapting it while writing tests biases the tests toward the implementation, which is testing-after in disguise.

Only for throwaway prototypes, generated code, or configuration files, and only after asking your human partner. Rationalizations like "too simple to test" or "I'll test after" are red flags that mean you should restart with TDD.

You are likely testing mock behavior instead of real behavior, a common anti-pattern. Assert on real component behavior, mock only at the level of slow or external operations, and mirror complete API response structures in your mocks.