Integration Testing: What is it? – A Full Guide

Integration testing involves taking units or modules and testing how they work once integrated with a system’s other units. A module can be something as simple as a bug fix, a story, or something more extensive such as adding a new feature or third-party option to a system. 

When and How to Perform Integration Testing

There are four levels of software testing: Unit testing, Integration testing, System testing, and Acceptance testing. A developer will write short test scripts during unit testing to verify the individual component or module meets its specified requirements. After this, the unit is ready to integrate with other modules. Integration testing can begin to verify how the components interact, call on each other, or perform exclusively based on the system’s needs. The process is done before system testing, although integration testing will continue throughout the project’s life by integrating other modules or third-party systems.

Test Cases

The first step for integration testing is to create a test plan, suits, and cases. Creating test cases to cover all possible scenarios requires careful thought. The tester should understand how data enters and exits the system and know the primary function and flow of the system as a whole. The tester will also need to consider the possible use of imitation programs called stubs and drivers. 

Stubs and Drivers

When performing integration testing, some modules may need to call on other modules that have not yet been created. In this case, a tester can use imitation programs called stubs and drivers to perform behaviors of the absent modules. For example, the tester can use a stub when an upper-level module needs to call on a lower-level module not yet integrated. A stub is a piece of code that can receive the data sent from the upper module and return a response. Likewise, when a lower-level module needs information from an upper-level one, a driver is a piece of code that can mimic the response. Examples with explanations of each are below.

Tips for Success

Communication with the development team is vital for success. 

• Sometimes modules are written by several developers who can be unaware of how their contributions will interact with modules written by others. It’s the tester’s job to communicate any discrepancies with the developers, and the sooner, the better. 
• The tester should consider both functional and non-functional tests. For example, if a new payment gateway is being added, the test plan will most likely include API testing. If the new feature is expected to deliver a lot of new traffic, performance testing may be required.
• When test planning, consider any third-party integrations early on. It may take some time to get proper access or the information needed for testing. 

After creating the test cases, the tester will need to decide how to approach integration testing. The project size, type, and methodology used often will often determine the approach.  

Integration Testing Approaches 

There are two types of approaches for integration testing. Iterative is often used as an agile method and is the most popular. Other methods, such as the Big-Bang approach, are not used as often but can be very helpful depending on the project. 

Iterative Approaches 

• Top-Down Approach – The tester starts integration testing with the highest-level module at the top and works their way down to the lowest module. This option is helpful because you can test essential modules first. If the lower-level module isn’t available for testing, you can use a stub as a substitute.
• Bottom-Up Approach –The tester starts with the lowest module and continues to the top in this approach, as opposed to the previous. This option is useful when there are multiple layers of lower-level modules. You might start at the top and find an issue right away. It would be challenging to narrow down the root of the problem when so many modules could be responsible. The tester can ensure each level works as intended before starting at the bottom and working upwards. If an upper-level module isn’t available for testing, a tester can use a driver as a substitute. 
• Hybrid Approach – This method blends the two integration testing approaches mentioned above. The top and bottom-level modules are often tested simultaneously until finally meeting in the middle after testing. This approach makes use of both stubs and drivers. It is most useful when testing substantial projects like entire operating systems, or when the team has many testers available to perform testing from both ends.

Other Approaches

• Big-Bang Testing –This approach waits until the completion of all components to then test them simultaneously. Waterfall projects use this method. 
• Case-by-Case – If a stable system already exists and a new module such as a third-party system is introduced as an additional feature, how much testing is needed may be decided on a case-by-case basis. 

Example

Let’s pull this all together using a simplified, real-world example. Think about testing an e-commerce site that will allow a user to checkout with an account or as a guest user. The modules could look something like this:

Once the site is created, level 1 can be tested. As the other modules in level 2 are done, they can be integrated and tested with level 1 and individually. 

Now imagine adding new features to the site. The modules could look something like this:

The promo code function needs to be tested both as a user with an account and with guest checkout. The loyalty program is also ready for testing. It will need to be tested by a user with an account, both with and without a promo code. 

This basic example shows how to do integration testing for a new or existing project. Ongoing integration testing is required whenever a new feature is added. Each time integration testing is completed, system testing can begin, which will ensure the system works as an entire project.

Benefits

Integration testing offers several benefits. 

• System testing can be done quicker and with more efficiency. Confirming that individual modules work increases tester confidence when testing the entire system. 
• The tester saves time by finding issues earlier in the SDLC when performing integration testing, which makes them less expensive to fix.
• Integration testing can give the tester a more in-depth understanding of the project. When the tester has more knowledge, they can test at a deeper level and build more confidence within the system. 

Conclusion

Integration testing allows the tester to confirm that a new module works as intended. In addition, testing verifies that all components work together to enhance the project after integrating the new module into the system. Integration testing occurs after unit testing but before system testing and is an ongoing practice to perform anytime new features or modules are added to a system. 

Strong knowledge of the system and detailed requirements from the project team are essential for successful integration testing. Skilled testers will consider the end-user and their expected actions when writing test cases and test plans. Test plans for integration testing will always differ depending on the nature of the system and its intended use. The project’s methodology will direct the tester towards an iterative approach for agile products or an alternative approach for waterfall methods.