Unit, integration, and E2E tests explained

WHAT THIS TESTS Whether you understand the scope, cost, and purpose of each test layer and can place them on the test pyramid.

A GOOD ANSWER COVERS Unit tests verify the smallest pieces, a single function or class, in isolation, with external collaborators like the database or other modules mocked or stubbed. They are fast, deterministic, and you write many of them. Integration tests verify that several components work together correctly, for example an Express route handler talking to a real test database or another service, catching bugs that live in the seams between units. They are slower and fewer. End-to-end tests drive the entire running application the way a real client would, sending HTTP requests to a deployed instance or automating a browser through Supertest, Playwright, or Cypress, validating complete user journeys. They give the most confidence but are slowest and most brittle. The test pyramid recommends many unit tests, fewer integration tests, and the fewest E2E tests.

COMMON WRONG ANSWERS Calling a route test that touches a real DB a unit test, treating all tests as interchangeable, or writing only E2E tests because they feel most realistic.

LIKELY FOLLOW-UPS Where mocking belongs, why the pyramid shape matters, flaky E2E tests, and how Supertest fits integration testing.

ONE CONCRETE EXAMPLE Unit: test a formatPrice(cents) utility returns 12.50 for 1250, no DB involved. Integration: send a POST to /users via Supertest against a test database and assert a row was created. E2E: automate a browser to register, log in, and see the dashboard, exercising frontend, API, and database together as a user would.