Unit vs integration testing: What’s the difference?

The foundation of your test strategy is unit tests, and a smaller number of integration tests.

Developers have a job to create reliable, working software. But how do you know that your code works? Whether you’re developing a small app or a large system, you need to test your code.

What to know

  • Unit testing focuses on testing individual units of code in isolation, using specific test data, while integration testing examines how different systems or parts of the code interact with each other.

  • Unit tests are faster, easier to maintain, and validate the correctness of individual parts of the program, while integration tests are slower, more complex, and identify compatibility and integration issues.

  • Both unit and integration testing are important, and it’s good practice to write both.

There are several types of tests. To be confident in writing tests, you need to understand the difference between them. Unit and integration testing are two common types of testing. The main difference between the two is the scope of the test: unit tests are about testing a single unit of code, while integration tests are about testing how different parts of your code work together.

A man at a machine, doing some testing

Unit testing explained

A Unit test is a way of verifying the correctness of a software program by testing a single part of it, in isolation. In practice, the term “unit” in “unit test” usually means testing a single function or method.

Unit tests are usually small enough that they run quickly, and can be run often. This allows developers to quickly test their code, and to catch any errors before they become a problem.

Unit tests should also be isolated, which means that each test should run independently from other tests. The outcome from one unit test should not affect another.

An example

You write a test for a function in your application that calculates the total price of an order. The function takes a list of products and returns the total price.

You call the function with a list of products, and verify that the result is correct.

This is a unit test. It tests a small piece of code, and it’s isolated from other tests.

Integration testing explained

Integration tests are a way of testing how different parts of your code work together. Integration tests are usually slower than unit tests, because they have a wider scope, and are often run less frequently.

These types of tests are designed to test the interaction between components of a system.

An example

You write a test that logs on to your application, and verifies that the user was logged in successfully.

This test might involve several components:

  • making a request to your logon method
  • the logon method might call an API to authenticate the user
  • the logon method might save the user’s details to a database

This is an integration test. It tests how different systems or parts of your code work together.

What’s the difference between unit and integration tests?

This table summarises some of the key differences between unit testing and integration testing:

  Unit testing Integration testing
Purpose Validates individual parts of a program Verifies how parts work together
Scope Focuses on individual units Tests interaction between units
Isolation Tests parts separately Tests parts together
Granularity Tests small, focused parts Tests end-to-end scenarios
Environment Uses mocks or stubs in place of external dependencies Uses real or simulated integration environment
Data used in the test Specific test data, often to make a certain event or error happen Realistic, production-like data
Execution speed Faster execution times Slower, due to larger scope
Level of complexity Less complex, due to isolation More complex, due to interaction
Bug detection Identifies logic errors Identifies compatibility and integration issues
Maintenance Easier to maintain Challenging, as dependencies can change often

Which is more important?

It might be tempting to think that you can focus on one type of testing, and ignore the other. But both unit and integration testing are important, and you should have a good mix of both.

Unit testing focuses on testing logic within a software program, which can be subject to programmer error.

But most software applications also depend on another system – for example, a program might depend on a database or an API. Integration testing focuses on testing how the different parts of a software system work together.

If you’re unsure which to write first, people suggest writing unit tests first, and then adding integration tests as you go. This is perhaps because unit tests are smaller and easier to write, and they can help you to refactor your code.

The test pyramid

The test pyramid, originally by Mike Cohn, is a good visual illustration for the relative size and importance of tests. The test pyramid shows that the bulk of tests are often unit tests, with a smaller number of integration tests:

The test pyramid

The test pyramid, showing the scope and speed of tests

Vladimir Khorikov, in his book Unit Testing Principles, Practices, and Patterns, says:

Check as many of the business scenario’s edge cases as possible with unit tests; use integration tests to cover one happy path, as well as any edge cases that can’t be covered by unit tests.

Closing the loop

In software development, testing is essential to ensure the reliability and functionality of code. Unit testing focuses on testing individual units of code in isolation, using specific test data to validate their correctness. On the other hand, integration testing examines how different parts of the code interact with each other, using realistic production-like data to identify compatibility and integration issues.

Both types of testing are crucial, and a balanced combination of unit and integration tests will help you build great, reliable software.

Tom Donohue

By Tom Donohue, Editor | Twitter | LinkedIn

Tom is the founder of Tutorial Works. He’s an engineer and open source advocate. He uses the blog as a vehicle for sharing tutorials, writing about technology and talking about himself in the third person. His very first computer was an Acorn Electron.

Join the discussion

Got some thoughts on what you've just read? Want to know what other people think? Or is there anything technically wrong with the article? (We'd love to know so that we can correct it!) Join the conversation and leave a comment.

Comments are moderated.