The software development lifecycle consists of many stages to ensure that the final deliverable meets the requirements. Testing software is one such integral part of the development process. The two most popular tests for any software are — unit testing and integration testing.
On a high level, Unit testing allows us to test a single component of code in isolation which is usually a single method or class. On the other hand, integration testing enables us to test the connection or flow between different components. These components can be several pieces of code, services, APIs, database connections, etc.
In this article, let’s explore the differences between unit testing and integration testing.
Approaches to Software Testing
When it comes to software testing, there are several approaches that developers and testers take to ensure the integrity of the software. Depending on what you need to test, you can decide which method suits you. However, some tests are a must for every software. Hence, we can categorize them as the base layers of the testing cycle.
It’s also important to understand that these different test categories are not exclusive. Instead, they complement each other. The two most frequently used testing approaches are unit testing and integration testing. These basic-level testing approaches are primarily suitable for any software. Therefore, it’s essential to include both in your continuous integration pipelines. In order to avoid confusion, let’s first discuss each of these techniques before diving into the core differences between them.
On a surface level, there are three basic kinds of testing -
- We use unit tests to find bugs or errors on a single unit or code. We use them to verify the logical integrity of a method or a class. They are easy to implement and very fast to execute. They require significantly fewer resources.
- Testers use integration tests to validate the integration of several components of code. They use it to check whether the services, APIs, and databases work together as intended. We can use them to find bugs or errors at the interface level.
- End-to-End are comprehensive tests that QA team uses to verify the integrity of the complete application right from the start. It includes testing code, services, APIs, databases, UI, etc.
What is Unit Testing?
Unit testing is a testing method that focuses on a single piece or unit of code. We use them to test a methodology in isolation. It determines the logical integrity of a method or a class. Simply put, we use them to determine whether a piece of code does what it’s expected to do.
For example, consider an application that books airline tickets. There might be several services and APIs in the code, each of which might have several methods/functions with their own purpose. There might be a service that allows users to log in, another that allows them to input details such as source and destination, etc. Suppose, in a service, we have a method that filters flights within a specific price range.
In this case, if you want to test this method, you need to ensure that, based on a given price range, the actual output has the same number and description of flights that are expected. This is called unit testing.
Challenges in Unit Testing
We might encounter several challenges during unit testing. We cannot test all pieces of code in isolation. That’s where things get tricky. An important thing to notice about unit testing is its execution speed. As discussed, unit tests are meant to be run in isolation. Hence, we want them to run directly without the involvement of any other system. Usually, there should be no dependencies on the OS, file system, or network capabilities. However, there might be some dependencies on other APIs or services. If there are dependencies with other services, we can mock or stub them to return things we expect during the process.
Also, there are access modifiers in programming languages that make it difficult to access private members. In these cases, you must create helpers to access them outside their scope.
Unit testing is the heart of test-driven development. In this case, we write the unit test cases before we start the actual development. This is to realize the actual expectation of a single unit before its rollout.
The rule of thumb for Unit Testing
As discussed earlier, unit tests target single code units and mostly target code chunks instead of visual parts. Moreover, only developers use them to validate the logical implementation of a piece of code, unlike other tests (acceptance testing, etc.), which are meant for stakeholders. So far, we have discussed how unit tests must be written and what they should target. Now let’s discuss some unique properties of unit tests.
A test case is not a unit test if -
- It talks to a database.
- It can’t run parallel with other unit tests. They should not be dependent on other cases.
- You have to tweak your environment configuration to run the test cases.
- It communicates with the network or file system.
Why is isolation good for unit testing?
There are a few points to back this up. Firstly, if we want to create several unit test cases to cover each part of our code, we need to ensure that they do not eat up the performance and execution time of the code. Hence, we must make sure they run as quickly as possible. If there are dependencies with the database or file system, it will naturally slow them down.
Unit test cases must be deterministic. If a unit test fails or passes, it must continue to do so until someone alters the faulty piece of code. Moreover, if a test case relies on other tests, there might be a possibility that its status might be changed for reasons other than the underlying code.
Finally, unit test cases have a super precise scope of feedback. Since a unit test case targets only a specific piece of code, we know that the fault is that code if the test fails. On the other hand, if the test case targets a database, a file system, and some code, we don’t know where the point of failure is.
Integration Testing
We have learned that only testing the isolated pieces of code is not sufficient to determine the software’s integrity. In such a case, it’s better to test how different parts of the application interact and work together. This process is called integration testing.
Unlike unit testing, integration testing considers the side effects of the code from the beginning, which may even be desirable at times. Let’s consider the example that we used before. Suppose there’s a service that fetches the user’s details from the database and auto-fills it. If we want to test this logic, there’s a dependency on the database here. In these cases, developers need to prepare, query, and mutate the database. They often mock these external dependencies, just like in unit testing.
Integration testing helps us to spot not-so-obvious issues or bugs that might have been caught by examining a specific unit’s implementation. It figures out bugs in the interplay of multiple components, which are often difficult to reproduce or track.
Ideally, developers prepare and execute unit test cases first to validate the logical integrity of specific methods. After that, they prepare integration tests to ensure that several methods or components interact with each other as they are supposed to. In the above example, an integration test here would run the same test cases against a real database as opposed to unit test cases that use mocked data. “Integration testing” is a general term and confines any tests where we involve multiple components.
Types of Integration Testing
There are different types of integration tests that are designed to target different types of integrations with the software units. The most common types of integration tests are:
- Top-down: Top-down integration testing has a flow from the top-level modules to the lower-level modules. This means they test whether the higher-level modules can communicate with the lower-level modules.
- Bottom-up: Bottom-up integration tests the communication flow from lower-level modules to higher-level modules.
- Big-bang: It involves testing all the different types of modules as a single entity, all at once.
- Sandwich: Sandwich integration testing combines pairs of modules and tests them together.
Why do we need Integration Testing?
Integration testing helps to test the overall functionality of the application by involving multiple components together. Let’s discuss a few other use cases of integration testing.
- We conduct integration tests to check the load, performance, and functional behavior of the system or software.
- Unlike unit tests, integration tests verify if the components work well in connection with the databases, file systems, network components, other services, etc.
- They help us determine if there are any gaps in the interaction between various components and detect gaps not identified in unit testing.
Why do people mix them up?
There are a lot of similarities between unit testing and integration testing, which may confuse developers and testers. Fundamentally, both these tests are functional tests. We use them to catch issues and bugs during the early development phase. We do both tests to ensure good quality and code coverage before release.
Ultimately, this will reduce the time needed for debugging in case of any errors or issues after release. Moreover, these tests help you reduce the time and effort required to maintain the code. Also, if any changes or refactoring are done to a piece of code, you can verify if that piece of code still holds the same functional value. In this way, both tests are correlated to each other. These tests play a vital part in the complete testing process of your project.
Differences between Unit Testing and Integration Testing
Although unit testing and integration testing share a few things, this does not mean we can use them interchangeably. In fact, there are quite a few major distinctions that set them apart. Let’s have a quick look at the detailed comparison below. This will give you a better understanding of how and when to use these two software testing techniques.
So how do you differentiate?
- As already discussed, we use unit tests to test each component of software or unit of code separately. On the other hand, in integration tests, we test the flow between two or more separate modules. We test how they work together.
- Another major thing to consider is that developers usually conduct unit tests during development. On the other hand, integration testing is done separately by the testing team.
- Unit tests are independent of each other. We can execute them at any time, in any order, or even simultaneously. But integration tests are usually done only after the unit testing and are done in a rigid order.
- If we find any errors during unit testing, it’s easier to debug and fix them. This is so because unit tests target a specific piece of code. So we know that the fault lies in that method or class. But in the case of integration tests, they are more complex and involve interactions with a lot of components. This justifies why an integration test is costlier than a unit test.
- In unit tests, we create stubs or mocks to mock the external dependencies, if any. In integration tests, we use real dependencies.
- Yet another clear difference between these two functional tests is that integration testing is black-box testing and unit testing is white-box testing.
- In the case of unit testing, the developers know the internal design of the application, while testers don’t need to see the code in integration tests. Hence, unit testing starts with module specification, and integration testing starts with interface specification.
Unit Test vs Integration Test in CI/CD
Automating tests in a CI/CD pipeline is necessary for a smooth delivery process. They need not be monitored and eliminates a lot of manual activities. However, we need to decide on which stages of the CI/CD pipeline we should trigger the tests.
Firstly, tests should always be run when somebody pushes a commit to the master branch, maybe as part of a pull request. This means that whenever there is a new commit in any of the pull requests, it should trigger a build that will also execute the test cases. This will protect the main branch from any faulty code being merged.
We should set up the tooling and pipeline so that the changes are only deployed when all the test cases are passed. Moreover, the code coverage on the new code is above a certain threshold. This failsafe is necessary to avoid delivering quick fixes without prior safe checks. Indeed, executing these tests would surely slow down your build time, but it’s worth it.
Moreover, there should be a mechanism to run such tests in your production environment. Also, there should be proper monitoring in place to notify whenever there is any failure. Since it’s best to keep the build time as fast as possible, using several unit test cases makes a lot of sense.
Every development team must have well-defined and reliable test setups that cover all the logical implementations. Also, running the test cases automatically in the CI/CD pipeline should be a high priority for any feature team. This will give your code healthy code coverage, and the software will be as bug-free as possible.
White-Box and Black-Box Testing
In white-box testing, the testers know about the internal implementations of the code. Whereas in black-box testing, the internal implementation is hidden from the tester. So why does the distinction matter?
It matters depending on who performs the tests. There are certain types of testing techniques that do not require coding skills. For example, UI testing, exploratory testing, etc. On the other hand, tests like unit testing are classic examples of white-box testing. Developers need to know the functional as well as the logical implementation of the code units to test them.
Hence, knowing about the distinction helps the decision-makers make educated decisions on which test suits their needs. Moreover, white-box testing relies too heavily on code implementations. Thus, maintaining them might be laborious and fragile.
Unit Test and Integration Test — White, Black, or Grey?
So under which buckets do these testing techniques fall? The correct answer would be neither or both. Let’s take a look at the below scenarios.
Unit Test
TESTING
Usually, unit testing falls in the category of white-box testing. It relies on the implementation of the code and its logical structure. However, sometimes unit testing can also act as black-box testing. Let’s take a look at the two possible cases.
For example, suppose your team practice bottom-up test-driven development. In this approach, the development is done by creating low-level unit test cases. Post that, you slowly work your way up toward higher-level test cases (acceptance level). Clearly, this scenario falls under the white-box category.
On the other hand, if you use a top-down test-driven development approach, you would start by writing higher-level test cases. You will have to use test doubles to fill up the dependencies to be written. Gradually, you will be moving toward writing lower-level cases. In this case, the initial behavior can be considered black-box testing. This is so because you are initially considered with the API level implementation rather than internal code.
Integration Testing
It’s the same case with integration testing as well. We have scenarios where it can act as both white-box and black-box techniques.
For example, suppose we have a Java application integrated with the GitHub API. Herein, we can create a module allowing us to input a username and display a list of repositories belonging to the user. To test this, we can create an integration test case that would use a real instance of the GitHub API.
However, the GitHub API is indeed a black box for us. We don’t know its internal implementation. We would simply rely on a public interface.
On the other hand, we can write a test case that integrates multiple parts of our code, in such a way that it has a coupling with the internal structure of our code. These cases would certainly fall into the white-box category.
Final Thoughts
Both unit testing and integration testing are crucial parts of any project following a software development lifecycle. Moreover, it’s also evident that both these techniques cannot replace each other. Rather, they complement each other.
Each of these techniques serves its purpose. On one hand, creating unit tests is often faster, but the stability and reliability of integration tests build confidence among the stakeholders. Hence, it certainly makes sense to adopt both these testing strategies to ensure that the software is bug-free and will continue to be.
Also, we discussed how essential it is to integrate our CI/CD pipeline with automated testing methodologies. And also, when triggered at proper stages, how they help us monitor functional and logical bugs in the system.
To sum up, although both these functional testing techniques have some similarities, there are also multiple differences. They each have their use cases; performance-wise, unit tests are much faster and can be run parallelly. Whereas, to test the integration of APIs and services, integration tests are a boon. The key to deciding which one to use depends on a good understanding of their differences.
Originally published at https://testsigma.com on October 19, 2022.