intermediate
Unit, integration, and E2E tests
Separate isolated logic checks, real collaboration checks, and browser or service journey checks so failures point to the right layer.
Unit tests isolate a module and replace collaborators with doubles—they verify logic, branches, and invariants quickly. Integration tests exercise real collaborators: database queries, HTTP clients, message queues, or module wiring—failures point to boundary mismatches. E2E tests drive the system as a user or external client would, validating full journeys across UI, API, and infrastructure.
Choosing the layer matters: a pricing bug in pure calculation belongs in unit tests; a broken SQL join belongs in integration; a checkout button that never enables belongs in E2E.
On interviews: give a concrete example of the same feature tested at two layers and explain what each layer would miss if omitted.
Common pitfalls: mocking everything in "integration" tests, duplicating the same assertion at all three layers, or calling API tests E2E when they never touch the UI.
The trade-off is isolation speed versus realism—deeper layers catch more but fail slower and need heavier fixtures.
Checklist:
- Define unit, integration, and E2E by failure signal.
- Pick the shallowest layer that still exercises the risk.
- Avoid triple-testing identical behavior without new signal.