What’s the difference between unit, integration, and e2e tests?

In modern web development, automated testing is essential for building reliable applications, but not all tests are created equal.

You’ve probably heard the terms unit test, integration test, and end-to-end (E2E) test thrown around. But what exactly do they mean? How are they different? And when should you use each?

🧪 1. Unit tests: testing functions in isolation

A unit test checks the smallest piece of code, usually a function or method, in complete isolation.

Example:

function add(a, b) {
  return a + b;
}

test('adds two numbers', () => {
  expect(add(2, 3)).toBe(5);
});

This test doesn’t rely on a database, API, or UI. It just checks that add returns the correct value.

✅ Pros

• Fast to run
• Easy to debug
• Great for logic-heavy code
• Encourages small, pure functions

⚠️ Cons

• Doesn't catch integration bugs
• Can give false confidence if mocked too much

🔄 2. Integration tests: testing modules working together

An integration test checks that multiple parts of the system work together, for example, a function calling a database or API.

Example:

// Service that queries a database
async function getUser(id) {
  return await db.users.findById(id);
}

test('gets user from database', async () => {
  const user = await getUser('123');
  expect(user.name).toBe('Alice');
});

This might hit a real (or in-memory) database and check that everything from the query to the result works as expected.

✅ Pros

• Catches real-world bugs across layers
• Tests more realistic behavior
• Validates data flow between components

⚠️ Cons

• Slower than unit tests
• Harder to isolate failures
• Can be flaky if external systems are unstable

🌐 3. End-to-end (E2E) tests: testing the whole application

E2E tests simulate a real user interacting with the application, from the UI to the backend and database.

They often use tools like Cypress, Playwright, or Selenium to click buttons, fill forms, and verify expected outcomes in a browser.

Example (with playwright):

test('user can log in', async ({ page }) => {
  await page.goto('http://localhost:3000/login');
  await page.fill('#email', 'user@example.com');
  await page.fill('#password', 'password123');
  await page.click('button[type="submit"]');
  await expect(page).toHaveURL('/dashboard');
});

✅ Pros

• Tests the app exactly as a user would use it
• Verifies that all layers work together: frontend, backend, auth, DB
• Catches real regressions

⚠️ Cons

• Slowest test type
• Can be brittle or flaky
• Harder to maintain
• Needs more infrastructure (servers, data seeding)

🧱 Testing pyramid

A good testing strategy usually follows the testing pyramid:

▲
   | E2E tests (few, broad)
   | Integration tests (some, mid-level)
   | Unit tests (many, fast, isolated)
   ▼

Why?

• Unit tests catch most logic bugs quickly
• Integration tests verify the system's behavior
• E2E tests ensure real-world scenarios don’t break

🧠 Conclusion

Each test type serves a different purpose:

A well-tested app combines all three: fast feedback from unit tests, confidence from integration tests, and real-world validation with E2E.

Don’t pick one, balance them based on your project’s needs.