What is integration testing?

Question

Accepted Answer

**Integration testing** verifies that multiple **components or units work correctly together** — testing the interactions and integration points (like code with a database, services calling each other, or modules combined). It catches issues that unit tests (which isolate units) miss.

## What integration testing verifies

```text
Integration tests verify COMPONENTS WORKING TOGETHER (not in isolation):
  → code + DATABASE (does the data layer actually work with a real DB?)
  → service A calling service B / an external API
  → multiple modules/units combined; the integration POINTS between them
→ catches issues in how parts INTERACT — which unit tests (isolated) can't catch.
```

## Why integration tests matter (vs unit tests)

```text
UNIT tests isolate units (mocking dependencies) → fast, but DON'T verify real integration:
  → a unit can pass its tests but FAIL when combined (wrong assumptions about a dependency,
    a real DB query that's wrong, an API contract mismatch, config issues)
INTEGRATION tests use REAL (or realistic) dependencies → catch these interaction bugs:
  → wiring/configuration errors, data layer issues, contract mismatches between components
→ Integration tests verify the parts actually work TOGETHER.
```

## Example and considerations

```js
// integration test: the repository actually works with a (test) database
test('UserRepository saves and retrieves a user', async () => {
  const repo = new UserRepository(testDb);     // REAL test database
  await repo.save({ name: 'Ann' });
  const user = await repo.findByName('Ann');    // real query
  expect(user.name).toBe('Ann');
});
```

```text
→ SLOWER than unit tests (real I/O, setup); use a TEST database/environment
→ Test important integration points (data access, key service interactions, APIs)
→ Fewer than unit tests (the pyramid middle); manage test data/state carefully
```

## Why it matters

Understanding integration testing is important because it **catches a class of bugs that unit tests cannot** — issues in how components work together — so it's valuable knowledge for comprehensive testing.

While unit tests verify individual units in isolation (mocking dependencies), this isolation means they **can't verify real integration**: a unit can pass all its tests but fail when actually combined with others (due to wrong assumptions about a dependency, a real database query being incorrect, an API contract mismatch, or configuration issues). **Integration tests** fill this gap by testing **components working together with real (or realistic) dependencies** — verifying that code actually works with a real database, that services interact correctly, and that integration points function — catching the wiring, data-layer, and contract bugs that isolated unit tests miss.

Understanding this complementary relationship (unit tests for isolated logic, integration tests for real interactions) is key to comprehensive testing, since neither alone is sufficient.

Understanding the **considerations** — that integration tests are slower (real I/O and setup, so they sit in the middle of the pyramid with fewer than unit tests), use test databases/environments, focus on important integration points (data access, key service interactions, APIs), and require careful test data/state management — reflects practical integration testing.

Integration tests provide confidence that the assembled parts work, which unit tests alone can't give.

Since real applications are composed of interacting components and integration bugs (database issues, contract mismatches, configuration errors) are common and missed by unit tests, and since integration testing catches them by verifying components work together, understanding integration testing is valuable, practically-relevant knowledge — an essential complement to unit testing that catches interaction bugs, important for comprehensive testing that verifies not just isolated units but that the system's parts actually work together correctly.