Why I now write integration tests before unit tests — a shift in my testing philosophy

I used to follow the orthodox TDD approach: unit tests first, then integration. I've reversed this for most of my work and I want to explain why. **The problem with unit-first for API code:** Unit tests for API handlers require mocking the database, the auth layer, and any services. By the time you've mocked everything, the test is testing your mocks, not your code. When I ship a bug that affects real requests, the unit tests pass. **Integration-first for APIs:** I write a test against the real endpoint (test database, real auth). It's slower but it catches real bugs. Then if there's complex logic inside a service function, I add unit tests for that function only. Result: my integration tests have caught production bugs that my unit tests missed. My unit tests are now reserved for pure functions and algorithms where isolation genuinely makes sense. This isn't a universal prescription — unit tests for UI components, parsers, and data transformations are still great. But for HTTP API handlers, integration tests are usually the better first investment.