E2E tests drive a browser against the fully deployed system and simulate real user interactions. They give the highest confidence but are also the most expensive to maintain and run. Limit E2E tests to the most critical user journeys: login, checkout, core features. Everything else is covered by the lower levels.

When: For the two to five most important user journeys that represent the core value of the product.

UI tests verify the behaviour of the user interface: clicks, form inputs, state changes. In modern SPA frameworks like React or Vue, UI tests can run at unit test level without needing a browser. Visual regression tests additionally verify that the layout remains unchanged.

When: For interactive components, forms, state transitions, and critical UI flows.

Component tests test a service as a whole, with all internal layers, but with stubbed external dependencies. They give confidence that the service responds correctly to HTTP requests without spinning up the entire system. Faster than E2E tests, broader than unit tests.

When: To verify the behaviour of a service across all internal layers without needing external services.

Consumer-Driven Contract Tests (CDC) ensure that provider and consumer of an interface adhere to the same contract. The consumer writes tests describing their expectations of the API. The provider runs these tests against their implementation. If the provider breaks the contract, the test fails before the change goes to production.

When: In microservices architectures where multiple teams work independently on services that communicate with each other.

Integration tests verify one integration point at a time: database queries, filesystem operations, HTTP calls to external services. External services are replaced by stubs (e.g. WireMock) or local instances. They are slower than unit tests but give confidence beyond the boundaries of your own system.

When: For all places where serialisation or deserialisation occurs: REST calls, database access, queue messages.