tdd

Write one failing test for a single behavior (red), then write the minimal code to make it pass (green), and repeat for each remaining behavior. Avoid writing all tests upfront, since vertical one-test-at-a-time cycles keep tests responsive to real behavior.

Good tests verify observable behavior through public interfaces and survive internal refactors. Bad tests mock internal collaborators, assert on call counts, or test private methods, so they break whenever implementation changes without behavior changing.

Mock only at system boundaries such as external APIs, time, randomness, and the file system. Never mock your own modules or internal collaborators; prefer a real in-memory database like SQLite over mocking the database layer.

Yes, the patterns apply universally even though examples use Python and pytest. The same red-green loop, interface design, and mocking rules adapt to Go's testing package, Node's vitest, or any test runner.

Tests break during refactoring when they are coupled to implementation details like private methods, call order, or internal state. Rewrite them to assert behavior through the public interface so they only fail when actual behavior changes.

Refactor only after all tests pass, never while a test is red. Run tests after each individual refactor step, address smells like duplication, long functions, and shallow modules, and keep the public API surface unchanged.