Unit testing vs Integration testing: a QA perspective

What is unit testing?

Unit testing is a type of test to verify the output of a piece of code working as intended following a given input. Developers, who understand the code structure, mainly perform this white box testing method. Whether a piece of code under test is a function (method) or a class, an important rule to keep in mind is that the code to test should be independent or isolated from all dependencies such as file system, database, environment, etc. 
‍

In other words, if unit tests have been added and passed, they shouldn't fail if there are no changes in the code. Unit tests are the lowest level for test levels because they interact directly with the code that forms the application.

Examples of unit tests at a high level

Below are two examples of unit tests at a high level:
There is a function A that accepts two parameters and returns a value.

Example 1

Given that I have a function A that accepts two parameters, x and y,
When I input values for x and y
Then I expect function A to return value z 

This example is a good unit test because it's simple and has no dependencies. 

Example 2

Given that I have a function A that accepts two parameters, x and y,
When x receives value from API B and y receives values from file C
Then I expect function A to return value z‍

This test depends on another function and a file system, which is not a good unit test. So, how to test this function without dependencies? If you understand what API B and file C would return, you can create a mocking object to simulate the output of these dependencies. This will isolate the test.
‍

There are some reasons that the unit tests need to be independent:

• Unit tests are automated and run on every commit or pull request to ensure developers' changes will not break existing code. It should run on any developers' machines without any further configuration.
• Since unit tests run very often, they need to provide fast feedback. Having dependencies will slow down the execution.
• It’s hard to debug and maintain when it relies on other factors.

What is integration testing?

Integration testing is the next level of testing after the unit testing. The name of this test already self-explains the purpose: it verifies the output of the integration between different modules, components, or services. You can perform Integration testing both with a thorough or partial understanding of the code. Therefore, integration can be the white box or gray box testing, depending on what needs to be tested.
‍

A developer, or someone who understands the code, should write these tests. Example 2 in the unit testing section demonstrates how to conduct integration testing. It will use actual values from API B and file C to pass on to function A to validate if it returns the expected result. This test will use the real dependencies in the tests. Therefore, compared with unit tests, integration tests are more complex to write and debug (if tests fail). Integration tests also take more time to run and maintain.
‍

In some cases, the QA team can do integration testing without understanding the code. For example, that is a combination of multiple classes or modules. In that case, we only need to understand what is the input and the respective expected outcomes of the API.

After we test each module individually, we will then integrate each module. We then continue this stage by conducting Integration testing at this stage. We can perform integration testing with or without having all modules that are ready to be integrated.

Integration testing approaches

There are three approaches to integration, which are:

• Big bang integration: All modules need to be ready and integrated simultaneously. By using this method, all integration testing will be done at once. However, it has a drawback: the efforts to identify the failures are higher than in other approaches.
• Top-down integration: Integrating each module from top to bottom. The pros are that all modules don't need to be ready simultaneously to be integrated. For lower-level modules that are not ready, you can create test STUBS to verify the output of the higher-level modules. The cons? The main functionalities of the integration will be tested at the end (when all modules are integrated).
• Bottom-up approach: This is the opposite approach to the top-down method, where you integrate modules from bottom to top. To test the lower-level modules that are finished, you will create DRIVERS to simulate the input of higher-level modules. Like the top-down approach, a disadvantage of this method is that the issues can be identified at a later stage once integration is completed.

Importance of QAs understanding the concept of unit testing and integration testing

The Agile testing pyramid is a popular concept to define automation testing strategy for a software product that follows Agile methodology. In this pyramid, the Unit testing vs Integration testing are the lowest test levels and form the foundation of the testing coverage. If you correctly follow best practices, unit testing can cover 60-70%, and Integration testing can cover 10-20% of the testing pyramid. 

If you correctly implement Unit and Integration testing, they will cover 70-90% of the tests. The rest are then covered by other tests, which the QA team usually performs. Keep in mind that these numbers vary depending on the type of applications and testing processes used). If QAs can understand what has been covered at the lower levels, it's much easier for them to perform blackbox testing at higher levels such as functional testing, acceptance testing, and exploratory testing. 

Testers would have more confidence that functional behaviors have been tested earlier in other test levels then they will have more time to focus on exploring edge cases that have not been defined in requirements and suggesting UX improvements. Moreover, when identifying UI automated tests, they can save a ton of time because it is the fact that UI automated tests are the most expensive and flaky tests in the testing pyramid when it comes to implementation, execution and maintenance.

What if your team does not have unit and integration tests?

This situation is common in most start-up companies for many reasons. First and foremost, the development team understands the benefits of Unit testing vs Integration testing. Yet, it sounds reasonable that these tests are not the top priority because the core behaviors of the product keep changing to adapt to the market's needs.

Another reason to hold the team from putting these tests in the pipeline is that they do not have enough resources and capacities to include testing and feature development. In addition, they have to deliver new features quickly to catch up with the competitors that probably move faster in terms of user acquisition. Last but not least, some development teams don't see the benefits of these tests right away. Instead, they ignore them and rely on the QA team to find bugs created by their code.

Consequences of not having unit and integration tests

This seems acceptable in the short term because the QA team can perform testing manually, or even the developer can give a hand to do manual testing. However, in the long-term, when there are many more new features added, the time to get feedback from testing will increase, leading to slow delivery or buggy features if test coverage is not enough due to the pressure of fast delivery. It will lead to poor product quality, which negatively impacts user experiences.

If you are a QA tester in such organizations, it's an opportunity for you to speak up to impact the entire product's quality significantly. First, sit with your manager to understand the reasons holding the team back from building the quality from the ground up. If your manager is on the same page with you, that's awesome! The next step would be working with your manager to prove the benefits of these test types to the development team. From the management side, they should build a culture where everyone is responsible for quality, not only the QA team, and inject quality into the coding phase.

After you get buy-in from management, it's time to execute the plan. We  recommend using the Agile methodology to build incremental test coverage time by time so that you can learn and adapt to the current development process. 

Ask an engineer for a PoC

Because developers mainly write these tests, the first step should be asking an engineer to create a Proof of Concept (PoC) or a guideline for other developers to follow and write consistent tests. The reason is that the code might not be added by the one who creates the tests, so the one who writes the test needs to spend more time understanding the purpose of each piece of code they want to test. In this case, we should aim to write the most critical tests. Then, when all important functions have been covered, more tests can be added to improve the coverage.

The team should incorporate Unit and Integration testing into the new feature development parallel with adding tests for existing features. This one is much easier than testing existing features. If you follow the Scrum process, remember to include these testing tasks in the definition of done and keep in mind testing efforts when estimating the story points for a user story.

Last but not least, raising awareness of the importance of unit and integration testing will change the testing mindset of the team in the long run. A straightforward method that could influence the testing mindset is that when a bug occurs, the QA team should challenge the dev team on how they can prevent it from happening in the future. For example, if a bug occurs because there is no test for a specific method, a Unit test should be created. If a bug exists because of the integration of multiple modules, then you should implement an integration test.

Conclusion

Unit and integration testing might be out of the hands of many QAs. Still, if QAs can understand the basic concept of these tests, they will be able to:

• Improve their testing strategy
• Reduce duplicate and redundant tests
• Save tons of time to focus on areas where those tests have not covered, such as usability, performance, security

There are plenty of resources where you can learn about unit testing vs integration testing and how to implement them. Nevertheless, the best resources you should know about are developers working directly with the QA team. Why? Because you are all working on the same goal, which is to deliver a high-quality product to your customers. 

Suppose your developers haven't written any Unit or Integration tests. In that case, it's time for you to significantly impact the entire testing process by building the quality from the lowest level and creating a culture where everyone is responsible for quality.