Software Engineering Roadmap

Learn how to build, test, deploy, and maintain robust software systems.

Overall Progress0%

Integration & E2E Testing

Explanation

Unit tests prove that individual functions work in isolation, but real systems are made of many parts that must work together: a frontend, an API, a database, and the browser itself. Integration and end-to-end (E2E) tests verify those connections. This lesson explains the difference between unit, integration, and E2E testing, how browser automation works, how to write stable tests with good selectors and network stubbing, and how to avoid flaky tests. It builds directly on the Unit Testing lesson, moving from "does this function work" to "does the whole system work for a real user."

Why Unit Tests Are Not Enough

Unit tests check one piece in isolation, but they cannot catch problems where two pieces interact: the frontend sends the wrong shape, the API returns a status the UI does not handle, or a change breaks the login flow.

Unit vs Integration vs E2E

	Unit	Integration	End-to-End
Scope	One function/class	Several real components	The whole system
Environment	Isolated, mocked	Controlled (test DB)	Real browser + services
Speed	Milliseconds	Seconds	Seconds to minutes
Confidence	Low	Medium	High
Typical failures	Logic errors	Wiring between parts	Real user flows

The Test Pyramid

E2E (few)

Integration (some)

Unit (many)

Most tests should be fast unit tests; E2E tests are fewer because they are slower and more expensive to maintain.

Integration Testing

Integration tests run several real components together — for example, a service and a real database, or an API and its data access layer.

Controlled Test Environments

Use a dedicated test database, not production.
Use controlled configuration and seed data.
Clean up state so tests do not pollute each other.

End-to-End Testing

An E2E test drives a real browser as a user would.

Open browser

↓

Navigate to login

↓

Enter credentials

↓

Submit

↓

See dashboard

↓

Create an item

↓

Verify the item appears

Browser Automation

Tools such as Playwright and Cypress control a real browser programmatically: they locate elements, click, type, and read the page. They share the goal but differ in API and architecture.

Stable Selectors

Selectors that depend on fragile CSS or layout make tests break when the UI changes. Prefer stable, semantic identifiers such as data-testid attributes.

Selector	Fragility
.nav > div:nth-child(2) > button	Fragile — breaks on any layout change
[data-testid="login-submit"]	Stable — survives restyling

Network Stubbing

Browser

↓

API request

↓

Stubbed response

Stubbing replaces a real API response with a controlled one, so tests are predictable and do not depend on a live backend. For full confidence, some tests should still hit a real backend.

Test Data and Authentication

Use fixtures or factories for repeatable data.
Clean up created data after each test.
Never use real production credentials in tests.

Visual Regression

Visual regression compares screenshots to detect unintended visual changes. It is powerful but sensitive to fonts, environments, and rendering differences, which can cause false positives.

Flaky Tests

Causes: timing, network, shared state, unstable selectors, random data, environment differences.
Reductions: wait for elements instead of fixed sleeps, use stable selectors, isolate state, control randomness.

Debugging a Failing Test

Reproduce the failure.
Inspect logs and screenshots.
Identify which layer failed.
Isolate the cause.
Fix it and rerun.

Syntax

A Playwright login-flow testjavascript

1import { test, expect } from '@playwright/test';2 3test('login redirects to the dashboard', async ({ page }) => {4  await page.goto('/login');5  await page.fill('[data-testid="email"]', 'test@example.com');6  await page.fill('[data-testid="password"]', 'test-password');7  await page.click('[data-testid="login-submit"]');8  await expect(page).toHaveURL('/dashboard');9  await expect(page.getByText('Welcome')).toBeVisible();10});

The test drives a real browser, uses stable data-testid selectors, and asserts on the result.

Examples

Stable vs fragile selector

A stable selector survives restyling; a fragile one does not.

javascript

1// fragile2page.click('.form button:last-child')3 4// stable5page.click('[data-testid="submit"]')

Output

(the stable selector keeps working after UI changes)

Key Takeaways

Unit tests isolate behavior; integration and E2E verify the connections.
Follow the test pyramid: many unit tests, fewer E2E tests.
Use stable selectors (data-testid) to avoid fragile tests.
Network stubbing makes tests deterministic; some tests still need a real backend.
Flaky tests come from timing, state, selectors, randomness, or environment.

← PreviousUnit Testing Next →Clean Code & Refactoring