integration-testinglisted

# Integration Testing ## Overview Integration tests verify that components work together correctly across real boundaries — HTTP, databases, message queues, file systems. They answer: "do these pieces actually connect?" Unit tests can't answer that question because they mock the boundaries away. ## The iron law ``` NO CROSS-BOUNDARY BEHAVIOR SHIPS WITHOUT AN INTEGRATION TEST ``` If two components talk to each other and you only have unit tests, you've tested that each component works alone — not that they work together. That's where production bugs live. ## The test pyramid — when to use what ``` / E2E \ Few, slow, expensive, high confidence /----------\ / Integration \ Moderate count, real boundaries, focused /----------------\ / Unit Tests \ Many, fast, isolated, one behavior each /--------------------\ ``` - **Unit tests:** One function, one behavior, no I/O. Fast. Write many. - **Integration tests:** Real database, real HTTP, real file system. Test the boundary, not the business logic behind it. Write enough to cover every boundary. - **E2E tests:** Full user flow through the running application. Write sparingly — they're slow and brittle. **Default rule:** if the behavior crosses a process, network, or storage boundary, it needs an integration test. If it doesn't, a unit test is sufficient. ## Core principles ### 1. Isolated state Each test runs against a clean state. Techniques: - **Database:*