Integration testing is a form of quality assurance (QA) software testing, that combines software component and tests them as a group rather than individually.
Integration testing is like a food critic at a restaurant.
A food critic is going to enter a restaurant and sit down. Throughout their experience, they are going to analyze and assess the quality of the restaurant, everything from ordering their food, to how it tastes, to the restaurant's ambiance.
A critic isn't going to assess each component of the restaurant individually, but rather as a whole. They aren't going to ask for the raw ingredients of their meal, they are going to order it whole and assess it as a complete group. They aren't going to break down the waiter's components, assessing their tone of voice, talking speed, or posture. They are going to review the process of ordering food as whole, providing an assessment on the process of all the components grouped together, rather than individually.
At the end of their experience, the food critic is going to give a series of scores/reviews that readers will interpret as an opinion on the entire restaurant.
Integration testing is a form of quality assurance with the goal being to ensure that different components of code work to their specified functional requirements.
It's one thing to know what a integration testing means, but that is worthless if you don't know why you should know what staff augmentation is in the first place. Let's break down the importance of this tech term based on two high level categories. We'll walk through an explanation as well as provide a score, 1-10, that shows you how much you should care about integration testing.
The first will be if you do not have a product yet. This means that you don't have a physical product. Maybe you're in the ideation phase, or maybe you're almost ready to start development. Whichever it is, we'll get into why integration testing is important and why you should or shouldn't care about it if you do not have a product.
If you don't have a product yet, then you don't really need to worry about integration testing as you don't need to perform any quality assurance (QA) because you don't have a product.
The second category is if you do have a live product. Maybe you just launched your business or maybe it's been live for years and you're continuing to improve its quality. Regardless of the scenario, if your product is live, integration testing carries a different weight.
If you do have a product, then you should look into integration testing and how it can strengthen the integrity of your product. You need to determine what stage of product development you're at. If you are building your scrappy MVP, then integration testing probably isn't worth your time. If you're pushing out V1 and intend to scale your product, then this form of quality assurance testing is likely worthwhile.
So you know what by definition. You know if you should care about it or not depending on your situation as a business/company/product. To dig in deeper, we will walk through some examples so we can make sure you really have a solid grasp on integration testing.
There are four common strategies to Integration Testing: Big Bang, Top-Down, Bottom-Up, and Sandwich. Let's break down these forms of quality assurance as well as walk through some brief pros of integration testing as well as cons of integration testing as you explore this avenue of QA further.
Big Bang integration testing is when all of the components are combined and tested at once. The Big Bang method may seem more time-friendly at first because all tests are performed at once. However, the method can be less effective in the long run since it only tests the system as a whole and doesn't isolate specific components. The Big Bang method may therefore cause you to overlook potential errors, leading to more issues later.
The top-down method of integration testing involves simulating the lower level components that have yet to be integrated to the system. The top-down method allows the tester to write placeholders, known as stubs, for lower-level modules that haven't been implemented yet. Since the tester knows the expected outcome of these lower-level modules, they can simply write a stub that spits out the desired output.
Top Down offers several advantages including quicker testing. This is because stubs can be written more quickly than the lower-level modules they are replacing. In some cases, lower-level modules may depend on external input or even components from other teams, so it will save time to replace them with stubs when testing top-level components.
In contrast to top-down, bottom-up integration testing is when you test the lower levels of the system first. As the higher modules are completed, the tests continue, but always starting with the bottom. The bottom-up method is complete when the highest level component is tested and approved. While the bottom-up integration testing strategy is thorough, it can take more time and may not dedicate enough attention to testing key high-level components.
Sandwich integration testing, also know as hybrid integration testing, is a method that combines the advantages of both top-down and bottom-up strategies. Sandwich testing involves testing high-level modules and working down, while simultaneously performing tests on low-level modules and working up.
By combining both strategies, the tester is able to create a "best of both worlds" scenario. However, the sandwich method is often more expensive and effort intensive than the other strategies. Furthermore, if there are many interdependencies between modules, sandwich testing may not be a feasible approach.
Why should you perform integration testing? There are a few main arguments that you should consider, which are in favor of integration testing:
why would anyone want to skip integration testing if there are clearly established benefits? Well, there are two main arguments against integration testing: