test-driven-development

Follow the red-green-refactor cycle: write one minimal failing test, run it to confirm it fails for the expected reason, write the simplest code to pass it, verify all tests pass, then refactor while keeping tests green. Repeat for each behavior.

Write a test with a clear name describing one behavior, calling the API you wish existed, using real code instead of mocks. Run it and confirm it fails because the feature is missing, not because of typos or errors.

Simple code still breaks, and a test takes about 30 seconds. Exceptions exist only for throwaway prototypes, generated code, and configuration files, and those require explicit approval from your human partner.

Tests written after code pass immediately, which proves nothing about whether they test the right thing. They are biased by the implementation, verify remembered edge cases instead of discovered ones, and never demonstrate the test can catch the bug.

Never assert on mock elements, never add test-only methods to production classes, and never mock without understanding dependency side effects. Mirror the complete real API structure in mock responses to avoid silent downstream failures.

A hard-to-write test signals an unclear or overly coupled design. Simplify the interface, use dependency injection instead of heavy mocking, and extract test helpers when setup grows large.