What is integration testing?

The concept of integration testing raises several questions. The first is whether integration testing is necessary. The answer to that depends at least partially on the company in question. Smaller organizations with limited public interaction can be exempt from the need for integration testing.

However, for any company that works extensively with the public, integration testing becomes increasingly crucial. And if it’s a tech company that engages in releasing new software applications and tools, integration testing is even more vital.

An adage holds that a person never gets a second chance at making a good first impression. The same concept holds true for contemporary companies. Most of them are engaged in trying desperately to attract users, turn them into regular subscribers or consumers and maintain a successful and lucrative ongoing relationship with them. Such companies can’t afford to make many missteps when unveiling their blockbuster new programs or apps.

Consumers expect the technology in question to work as advertised, from its installation through how it interacts with other programs and systems. For this reason, for many organizations, integration testing is a necessary step of doing business.

In short, the goal of integration testing is to make sure that parts and systems work together dependably. But from a PR perspective, another goal of integration testing is to help protect the organization’s identity as a responsible company capable of doing business reliably in a modern context.

The term integration testing was developed over time to describe certain “waterfall” methodologies. In earlier times, software modules and related projects were created in a vacuum, leaving QA teams the considerable chore of testing pieces of the codebase individually and analyzing those test results before introducing them into a software system.

Integration testing is done through the creation and evaluation of test cases. The first phase involves successfully identifying integration points, which are the areas within an application where the different modules interact. When the integration points have been established, test cases are designed around them. These test cases are created to show how the integration points operate, depending on various input scenarios, real-world situations and anticipated outcomes.

With the data gleaned from test coverage, project stakeholders can make the necessary adjustments to the codebase, where all project data is stored.

Test cases used in integration testing help developers zero in on several specific areas of operation:

Another aspect of integration testing that escalates its overall complexity involves dependencies, which are relationships that exist between modules and/or components. Typical dependencies require that for one component to function, a related component must first operate as needed. Such dependencies must be considered when attempting to sort out potential problems in program execution.

There’s a standard sequence to the individual testing steps conducted when performing integration testing because such an ordered sequence gives developers a way to systematically evaluate different pieces of code in a structured fashion. The testing sequence typically begins with the checking of the simplest, individual components first—correcting bugs in lower-level modules before they negatively impact operation later. Then, the testing moves on to more elaborate integrations and evaluates their performance.

In addition to early detection of bugs, the usual testing sequence uses logical progression to mimic the code’s data flow, making sure that component interactions are tested in the correct order. Further, the testing sequence assigns a lower priority to less critical tests concerning low-level modules, allowing developers to dedicate their focus to the most essential operations.

In a traditional testing sequence, testing formats are examined in the following order:

1. Unit testing, which evaluates individual functions.
2. Integration testing, to see how components interact.
3. System testing, for determining the overall functions of whole systems.
4. Acceptance testing, which checks functions from a user’s perspective.

Integration testing is not the initial testing step in this standard sequence. Integration testing appears where it does in the process because the testing of interactions between individual components has already been accomplished through unit testing. The next level, system testing, moves the sense of scale-out even further to give testers a more macro view of an entire system and how well it all works together.

There are numerous types of integration testing techniques, but these are the most used to evaluate software systems.

The top-down approach is one of the two main types of incremental integration testing. It focuses on the main module and its workings before then evaluating the submodules and subroutines. One of the strongest attributes of this approach is that it can be used early in the process—even before the lower-level modules have been fully identified. Testers can use placeholders (called stubs) as a substitute for low-level modules.

Another primary example of integration testing is bottom-up integration testing, which switches the order of the testing sequence. In the bottom-up approach, the submodules and subroutines are the first to be evaluated. Then, this approach moves on to test the main module. And just as top-down testing uses stubs as placeholders when needed, bottom-up integration testing uses temporary modules called drivers as substitutes for high-level components that haven’t yet been identified.

Mixed integration (sometimes called sandwiched integration) combines the top-down and bottom-up methods. The main advantage of mixed integration is how it overcomes the enforced process sequence that limits both top-down and bottom-up testing (in directly opposite ways). With mixed integration, the testing can begin with either the main module or with the submodules and subroutines, as user needs dictate.

Another key way to conduct integration testing is through big bang integration testing. Here, all the individual units, components and modules present within a system are integrated and tested together at one time, as if it were a single unit. Big bang testing can provide a quick answer when the system works with all its various parts.

However, this form of testing is limited. If the process reveals that the system doesn’t work as expected, big bang testing can’t reveal which individual parts are failing to work in unison.

The following are some popular integration testing methods. Because they all might be the correct methodology for a software company—depending on its needs—they are listed here alphabetically:

• API integration testing: Application programming interfaces (APIs) are essential parts of computing, allowing software applications to interface with each other and successfully share data. API testing is a means of software testing that checks how the different APIs within a system work together. The goal is to see them functioning flawlessly as if these APIs were part of a single organized unit. The smoother the APIs operate with each other, the better the operation of the entire system.

• Automated integration testing: An essential part of the software development process, automated testing is another method that evaluates how software components work together. This integration testing process runs test cases based on the work of specialized testing tools and scripts. In this way, integration issues can be detected and fixed before deployment occurs. And because it’s automated, the entire system becomes more efficient and agile. Automated testing is a key element of continuous integration, the DevOps practice that relies upon a shared repository for constantly updated code changes.

• Black box testing: The black box analogy can be applied to any situation where it’s understood that the internal workings of the black box (whether that involves computer code or some other operational aspect, such as reported company earnings) are not subject to being fully understood. In the case of black box integration testing, it means that testers don’t want to pore over the specific codes used within different modules; instead, they prefer a simpler and quicker answer about whether the systems, components and modules work harmoniously.

• End-to-end testing: As the name suggests, end-to-end testing (sometimes called E2E testing) provides testers a way to check the functions of the entire system, from start to finish. Beyond that, E2E testing can mimic real-world test scenarios and set the stage for integration testing by incorporating test plans that determines which units are to be tested. E2E testing typically appears later in the integration testing process, after integration testing has been accomplished but before user acceptance testing.

• Functional testing: Of all software testing types, the one most dedicated to learning the sheer function of a system is functional integration testing (FIT). FIT provides validation that different modules or components can interact as needed and is useful in the way it can locate defects early in the software development lifecycle, before those issues can become full-blown problems. Testers typically perform functional testing after unit testing is conducted but before full system testing begins.

• Regression testing: Another testing framework is found through regression testing, which serves as an after-the-fact test environment for checking to see whether any changes made during the integration process have inadvertently introduced glitches to other parts of the system. When new features—such as new online payment avenues—are introduced, regression testing is used to help ensure that additions don’t derail systems that are already working correctly.

• White box testing: In direct contrast to black box testing, white box testing assumes that testers want to examine relevant code during the testing process in hopes of pinpointing problem areas and making corrective code changes to debug those problems, even though such an approach will almost certainly be more time-consuming. The phrase “white box” reflects this desire for clarity in the system’s inner workings—although the expression “clear box” might be a more accurate description of what testers seek.

Here again, this marketplace niche is served by numerous integration testing tools and frameworks. Here are some of the most popular:

• Citris: Citris serves Java’s huge user base (which makes it one of the world’s most popular programming languages) with an open source JavaTM framework. Citris can manage API usage (such as transactions) and generate testing messages.

• Katalon: Katalon Studio’s automation testing software incorporates the open source framework Selenium—a browser-based tool that lets testers write test scripts in various programming languages, including JavaScript, NodeJS and Python.

• Postman: API integration testing is well served by Postman. The tool also excels in the way that it enables collaboration and accommodates automation. Further, users can write a test without having to put that test in a collection or even save it. The tester makes a request in Postman and receives a corresponding URL.

• SoapUI: SoapUI provides an open source tool capable of testing web applications and executing integration testing. With it, testers get a graphical interface that supports the creation of test cases and enables users to easily work with test data.

Whether your company needs call for front-end or back-end evaluation and remediation, integration testing offers the means to evaluate the success of the connections that are now vitally important to making businesses operate with peak efficiency and maximized profitability.

As previously mentioned, there’s a considerable number of different integration testing methods, as software creators work to identify and develop an integration testing method for every possible need and all relevant configurations. And it’s working, because most software development companies understand the need for such testing. Some estimates assess that roughly 70% of businesses engaged in DevOps work are already using some form of integration testing.

So, which is the right integration tool for your business? Thanks to a receptive marketplace, it’s likely you can find one that capably suits your company needs. To figure out exactly what those needs are, we suggest you turn to one more famous old saying: “Know thyself.” As sayings go, it’s still useful advice—even for a postmodern world.