tdd

Write one failing test for a single behavior (RED), write the minimal code to make it pass (GREEN), then refactor while tests stay green. Repeat per behavior rather than writing all tests upfront, so each test responds to what you learned from the previous cycle.

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

Mock only at system boundaries such as external APIs, time, randomness, and sometimes databases or the file system. Never mock your own classes or internal collaborators; instead use dependency injection and SDK-style interfaces to make boundaries easy to stub.

Tests break on refactor when they are coupled to implementation details like private methods, internal mocks, or direct database verification. Rewrite them to assert behavior through the public interface, such as verifying a created user is retrievable via getUser rather than querying the database.

No. Writing all tests first is horizontal slicing and produces tests of imagined behavior tied to data shapes. Use vertical slices instead: alternate one test with one implementation so each test reflects real, just-written behavior.