Integration tests verify that selected components work together across a real boundary, such as application code plus a database. End-to-end tests exercise a complete deployed-style path through the user interface or external entry point and its supporting systems. The labels are less important than declaring what is real, what is replaced, and which failure the test can detect.
Who this is for: Software teams deciding which failures belong in module integration tests and which require a complete user workflow.
- Define every test by its entry point, real dependencies, replacements, and observable outcome.
- Use integration tests for broad contract and persistence coverage, then reserve end-to-end tests for critical journeys and wiring.
- Make test data, isolation, diagnostics, and failure ownership part of the test design.
Integration tests cross selected boundaries
An integration test may call an HTTP handler with a real database, verify a repository against its actual query engine, or render a component with a real router. It catches mismatched schemas, serialization, configuration, and collaboration behavior that isolated units miss. It does not need to include every external provider to earn the name.
State the boundary precisely. If email is replaced with a fake collector, the test proves the application requested a message but not that the provider accepts it. A separate contract test or staging probe can cover that interface. Precision prevents a green test from claiming confidence it never supplied.
End-to-end tests follow a complete path
An end-to-end test starts where a real user or consumer starts, such as a browser or public API, and reaches durable effects through production-like routing. It is valuable for sign-in, purchase, publishing, and other critical journeys whose failure can arise from component wiring, assets, cookies, redirects, or deployment configuration.
Full paths are slower and harder to diagnose. They also accumulate environmental failures unrelated to the behavior under study. Keep the set focused on important capabilities and a few high-risk variations. Do not reproduce every field validation rule through the browser when a lower-level integration test can exercise it more quickly and clearly.
Select level from the likely defect
Ask what could be wrong. A discount formula fits a unit test. A uniqueness constraint and transaction need a real database integration test. A cookie attribute, reverse proxy redirect, and browser navigation require a browser path. A third-party contract may need a provider sandbox or recorded schema check, depending on risk and provider capability.
Duplicate a small amount of coverage across levels when each test catches a different failure class. The central purchase rule may have fast unit cases, database integration cases, and one browser purchase journey. That is purposeful overlap. Repeating the same assertion through many slow paths without new evidence is maintenance cost.
Engineer reliable environments
Tests need isolated data with unique identifiers and dependable cleanup. Parallel workers must not mutate the same account or fixed record. Seed through supported APIs or controlled fixtures, freeze only the time you own, and wait for observable conditions instead of sleeping. Record screenshots, traces, server logs, and request identifiers on failure.
Run fast integration suites on ordinary pull requests and critical end-to-end journeys before merge or deployment according to cost. Quarantine is not a permanent destination for flaky tests. Assign ownership, reproduce the cause, and repair or remove tests that no longer represent product behavior. Required checks should be trustworthy enough that teams do not learn to ignore red builds.
Test member invitation at three levels
A workspace owner invites a person, and acceptance must create one membership without crossing tenants.
- Unit-test expiration and permission policy with fixed time and simple domain inputs.
- Integration-test the invite handler with a real database for uniqueness, tenant scope, transaction rollback, and duplicate acceptance.
- Replace email with a captured delivery contract in most runs and separately verify provider-facing payload compatibility.
- Add one browser test that signs in as the invitee, opens the link, accepts, and sees the correct workspace.
- Run a cross-tenant browser or API case and retain trace plus server request identifiers on failure.
Test boundary matrix
Map each important risk to the cheapest test that can truly observe it.
- Risk and consequence: rule, contract, persistence, routing, browser behavior, provider, or deployment configuration.
- Entry and outcome: function, handler, public API, browser action, returned value, record, message, or visible state.
- Reality map: actual database, network, filesystem, provider, clock, browser, proxy, and replacements.
- Operations: data isolation, parallelism, cleanup, timeout, retry policy, artifacts, and owner.
- Gate: local run, pull request, predeployment, scheduled probe, expected duration, and failure response.
Common mistakes
- Calling a browser test complete while replacing the database behavior that caused the production defect.
- Putting every edge case into an end-to-end suite and creating slow, opaque feedback.
- Sharing one mutable test account across parallel jobs and treating resulting flakes as unavoidable.
Try one
Place tests for an API rate limiter that uses a shared store and displays a retry message in the browser.
Unit tests cover window and quota calculations with fixed time. Integration tests use the real shared-store implementation to verify atomic concurrent increments, expiration, and tenant keys. A small browser or public API test confirms the deployed route returns the documented status and the interface presents the retry state. The answer should identify which dependencies are real at each level.
Sources
- GitHub test workflow guidanceGitHub's documented workflow for running repeatable Node.js tests in continuous integration.
- GitHub required status checksGitHub's documentation for protected branches, required checks, and review controls.
- MDN Fetch API guideMDN guidance for browser requests, response handling, credentials, and cancellation.