Integration testing is like inviting your two favorite groups of friends to the same birthday party and hoping they all get along.

For example:

You got your softball buddies and your board game friends.

Each of them individually is wonderful.

The question is…

Will they cooperate and “blend” when they’re all in the same room?

The only way to know is to perform an “integration test” by pulling them all together and seeing how they interact with one another.

And so it is with software development and design.

If you want each unit of software to merge seamlessly, you’ve got to merge them and judge the results.

We’ll show you some best practices for integration testing software, along with the differences between integration testing and similar forms of testing.

But first, let’s look at the definition of integration testing.

What Is Integration Testing?

Integration testing was #4 on our list of 18 different types of software testing. And that’s because of how critical it is to any good DevOps team.

Usually, integration testing comes right after unit testing to ensure all units operate in harmony with each other.

Oftentimes, a unit will be seen as functional on its own but may cause issues when interacting with other units.

That’s why software testing is so important, especially testing units as a group.

Also, most software projects have multiple developers writing code for different modules and units.

So integration testing lets you determine if the software different developers are writing are actually working toward the final goal.

But before you can perform an integration test, you have to do unit testing.

What is Unit Testing?

Unit testing is typically the very first test a developer performs on software.

The purpose of the test is to ensure the software performs well as a self-contained unit. That it works on its own without fail.

Now after unit testing and integration testing on those units, a developer will move onto system integration testing.

What Is System Integration Testing?

System integration testing is used to verify the performance of the complete system of software.

Basically, units of software are added together to create modules. Then those modules of software are integrated together into a complete system. And that’s what you’re testing.

Now to make sure we’re all crystal clear on the definitions and differences of all 3 types of testing we just laid out, let’s look at their comparisons.

Integration Testing vs. Unit Testing

While a unit may operate on its own, that’s no guarantee it works with others.

We want to drive home the difference between unit testing and integration testing and how one naturally leads to the other. And also how, if you don’t do integration testing, unit testing won’t mean much.

So here’s a simple table that spells out the difference between unit tests and integration tests:

Unit Testing	Integration Testing
Test each unit individually to make sure it works properly on its own.	Test units together to make sure they can be incorporated with each other without issue.
Can be performed any time.	Is performed after unit testing.
Can only detect errors within a single unit.	Can detect errors resulting from units interacting with one another.
Is usually performed by a developer (who requires in-depth knowledge of the code written for the unit).	Is usually performed by a team of professional testers.

System Testing vs. Integration Testing

After integration testing is performed on units, those units are combined into various modules which then have to be tested as a complete system.

Hence, system testing.

Just so you fully understand the difference between integration testing and system testing, here’s another helpful table comparing the two:

Integration Testing	System Testing
Tests how well individual units work together.	Tests how well the units and modules work together as part of the entire system, the entire product.
Is concerned with modules delivering the expected result.	Is concerned with the end-product meeting specified requirements.
Only performs functional tests.	Performs both functional and non-functional tests like usability, performance, load, etc.
Is both black box and white box testing that requires the knowledge of the units and interface.	Is a black box testing technique that doesn’t require knowledge of internal structure or code.
Is performed by developers and test engineers.	Is performed only by test engineers.
Seeks and finds defects between units, or a module, not the entire system.	Seeks and finds defects and issues that relate to internal and external interfaces that affect the entire system.
Simulates the interaction between two units.	Simulates a real-world test case.

What Are the Different Types of Integration Testing

Now that you have a full understanding of what integration testing is, let’s look at the various types of integration testing developers use regularly.

Big Bang Approach

The big bang approach is one of the most common types of integration testing.

Essentially, all units you want to test are smashed together and tested at the same time.

Now, this is great for small software projects or after you’ve done other forms of testing.

However, it does have its disadvantages.

For one, if there is an error or bug found, testers won’t know which module is responsible for it since they’re all combined together. They would have to detach a few and then run the test again, repeating that until they find the bug.

Also, this approach requires all modules to be designed and ready before testing can occur – creating a bottleneck and extending the time it will take for system testing and product release.

Incremental Approach

The incremental approach has you take two or more modules that are logically aligned and testing them in a single batch.

Then you add additional, related modules and test them together, and so and so forth until all of the modules have been successfully merged and tested with each other successfully.

The incremental approach is carried out by using either the bottom-up or top-down method, which we cover below.

Bottom-up Integration

A bottom-up integration approach takes one module from the lower level at a time and tests it with higher modules until all modules have been successfully tested.

This method is great for detecting fault localization. Plus, it wastes no time waiting for modules to be completed before testing, like big bang.

However, it’s not perfect.

Since the most critical modules, the ones at the top level, are tested last, they may be more prone to defects.

Top-down Integration

Top-down integration is the inverse of bottom-up. You test the modules at the top one at a time with the modules at the bottom until all modules have been tested.

The beauty of this model is that critical modules are tested first, so any major flaws can be found and fixed right away.

The downside of this model is that lower levels don’t get as much attention and may be tested inadequately.

Hybrid/Sandwich Integration

The sandwich/hybrid method combines top-down with bottom-up.

Basically, you test the top modules with lower modules at the same time as you test lower modules with the top modules.

Top and bottom are being integrated simultaneously, giving you the best of both worlds and better results.

Integration Testing Best Practices

Now before you can start implementing integration testing, it’s important to have a few strategies in place.

Here are a few integration testing best practices we recommend:

Do Integration Testing Before or After Unit Testing

We’ve clearly pointed out that integration tests are supposed to come after unit tests, and for many DevOps teams, that’s true.

The thing is…

If you’re following the principles of Agile software development, you don’t have to wait to perform major tests like integration.

When using methods like continuous integration, you’re constantly performing tests. According to Aaron Cois, CI is a technique designed to:

“Continually merge source code updates from all developers on a team into a shared mainline. This continual merging prevents a developer’s local copy of a software project from drifting too far afield as new code is added by others, avoiding catastrophic merge conflicts.”

In the Waterfall days of software development, you absolutely had to do integration testing after unit testing.

But today, you have a lot more flexibility to choose the right time to perform integration testing.

Separate Unit Testing Suites from Integration Testing Suites

While integration tests can be run at the times you need them, they shouldn’t be run at the same time as unit tests.

Developers need space to work on the business logic in the code by running unit tests and getting immediate feedback.

This is done to ensure broken code isn’t being committed to the mainline.

If their test suite takes a long time to finish – and unit tests should happen quickly – they may end committing bad code or stop running tests altogether.

This can also lead to a situation where unit tests are not properly maintained.

Keeping your test suites separate allows developers to run fast unit tests and saves the long integration testing process for the build server in another test suite.

Log as Much as Possible

If a problem arises during a unit test, it’s fairly easy to identify the cause and fix the issue.

But because of the scope and complexity of integration tests – usually spanning several modules and hardware components – identifying the cause of an integration failure is much more difficult.

To get around this, you should use log your progress.

Logging helps you better analyze the failure and maintain a record of potential reasons for the failure, as well as ruling out other reasons, narrowing down the true cause.

Create a Test Plan for Your Developers

Give your developers a common, shared document that lays out a logical sequence of actions to take when performing integration tests that they can reference any time.

This keeps testing consistent across the company and even allows project managers to allocate the correct resources to begin the integration testing process.

Here’s How to Do Integration Testing Right

A tool is only as good as the person using it.

You may have the infrastructure for properly performing integration testing, but you may not have the personnel.

Not to mention, hiring the right in-house developers and testers is a headache (and cost) that you probably don’t want to deal with.

And you don’t have to.

We can manage all of your testing for you.

With our managed testing services, you get:

• Fully customizable and scalable services for enterprise or program level requirements.
• Processes and environments needed to overcome testing challenges and achieve optimal results.
• Frameworks, tools, and most of all, highly trained staff in order to provide comprehensive support for your organizational goals.

Plus, we can handle the “big 6” of testing:

1. Security.
2. Performance.
3. Regression.
4. Functional.
5. Compatibility.
6. And test automation.

With a bonus #7 being integration testing.

Reach out today for reliable and effective software testing management.