Why integration testing is important for your business

Integration tests are used to determine whether independently developed applications work properly when connected. Many people assume that integration tests must be broad, when they can be accomplished with a wider scope.

It’s a good idea to have some background information, as it is with many things. Integration testing was first introduced to me in the 1980s. Since then, the waterfall has been the predominant influence on software development thinking. A design phase would be used to define the interface and behaviour for the various modules within a larger project.

The modules would then be assigned to programmers. Although it was not uncommon for one programmer to be responsible only for one module, it would still be a significant enough task that it might take several months to complete.

Unit testing is the first stage of testing. This could be used to verify that each module meets the specifications which were created at the design stage. After that, integration testing is completed. This involves combining the modules into the system or into sub-systems.

Integration Testing is used to verify that different modules work together as intended. To verify that they worked together, it involved activating multiple modules and running higher-level tests against them all. These modules can be part of one executable or they could be different.

Analyzing how the modules were integrated properly

Evaluation of a system with multiple modules was successful as expected.

These two things were simple to confuse. After all, how else could you examine the twitter and profile modules without activating them in a single environment? And conducting tests that tested both of the modules?

Another perspective, which was rarely considered since the 1980s, is offered by the 2010s. The alternative is to examine the integration between this profile and the twibbler module. This involves working the code that interacts with the twibbler module from the profile, and then implementing it against a TestDouble for all twibbler.

If the evaluation double is a faithful double of twibber then we can test all interaction behavior of the twibbler program without having to trigger a full instance of twibbler. While this may not matter if the modules are different from a monolithic application, it is important if the twibbler service is independent.

It will require its own environment, build tools, and network connections. These tests can be run against the in-process test twice or against an over-the-wire duplicate, using something like mountebank.

Integration testing against a double has one obvious drawback. It is not possible to determine if the double is faithful. However, ContractTests could be used to test this individually.

This combination of contract evaluations and narrow integration tests allowed me to be certain that I can integrate against an external service without having to run tests against the actual instance. This greatly simplifies my build process.

Although teams that do this may still do a finishing system test with all services, it is only a smoke test with a limited number of paths. A mature QA in Production is a must, and it’s possible that there will be no end-to–end method testing if this is the case.