A Closer Look at Integration Testing
Integration testing is the process of assembling various code modules which perform very specific tasks into a software system that uses them to perform more generalized applications. An example is using a module that stores and retrieves files with another that displays their names in a list and another that reads keystrokes as well as one that recognizes mouse pointer movements and clicks. All together they become a file management application.
These modules are typically written and tested individually by different developers with each focused only on their own particular piece of the overall puzzle of the application. They will perform extensive black and white box functional verification, commonly known as unit tests, on their individual modules. While unit tests allow a full span of both in band (expected values) and out of band (unexpected values) inputs, they depend on specification interpretation for testing those aspects of each module which must communicate with other modules. Once a unit tested module is checked in to the code control system, the developer moves on to the next module to be written and tested.
Once the modules that support a particular application function are collected in the management system, they are subjected to integration tests which exercise them in conjunction with each other. Integration tests cause data and operational commands to flow between modules which means that they have to act as parts of a whole system rather than individual code blocks. This typically uncovers issues with data formats, operation timing, API calls, database access and user interface operation.
Integration testing has a number of aspects that are not immediately obvious and are worth a closer look.
4 Ways to Use Integration Testing:
1. User Interface to Function
System integration means, in part, that the software responds in the expected manner to the user’s commands. Expected operation of controls individually and in concert with each other is an elementary aspect of integration testing. The user interface is a prime component of how the product will be judged by its user community and it must perform as expected.
Just as important is what happens when the user does something that was totally unexpected by the system’s design. Out of band and nonsensical control operations must be tested to see that they don’t crash the system and produce appropriate, understandable error messages. If the user’s control inputs cause the system to fail, it should fail gracefully.
2. Data Interface Operation
Code modules must continually exchange data and command structures as the overall system performs its functions. This is often supported by a data and/or command bus that facilitates module communication and is constructed of modules itself. Often, the code that channels data and commands is the most critical aspect of the system and has to operate under high stress conditions.
Integration tests should exercise the data/command bus under as many variations of load and content as possible. This activity is often under pressure from time and resource constraints but it is critical that the bus be able to support accurate, timely communications across the entire array of code modules that make up the system.
3. API Calls
The Application Programming Interface (API) is the most common channel by which the system communicates with third-party services. It has also become an accepted tool for connecting functional module groups within the system. This method of communication is valuable because it allows data and commands to be separated into separate function calls making the exchange much more robust and easier for humans to debug.
One of the main issues API calls represent for integration testing is the need to test them individually, exercising the entire range of data and command values as well as at least a few outside the acceptable range. This verifies that the connection between the system and the service connected to the API operates properly. That done, API calls must also be tested in functional groups. Often a service such as credit card verification requires several calls to the same interface that must coordinate in their timing of occurrence and content.
4. End-To-End
eCommerce has become so common that it is easy to overlook the impact it has had on software development. A major part of that impact is that the software that drives a website has to work with a database and an array of third party services to make an on-line business successful. From the front-end through middle-ware to the back-end that does the work, such a system has to be tested to verify that all its pieces work in concert.
End-to-end testing is the soul of integration verification. Done properly, the test facility sets up a complete system in what is called a ‘sandbox’ environment and then structures tests and test data arrays to drive it through every imaginable permutation of what the system has to do in the real world. User inputs stimulate the front end with data and requests which are communicated and massaged by the middle-ware to interact with the back end of API calls to third parties and database manipulations with all of this carefully monitored for accuracy of content and timeliness of operations.
Integration Testing is Where the System Finally Comes Together as an Operating entity.
Integration testing is designed to catch the defects that only appear when all the code is interacting with real world operating scenarios and making the decisions and responses that create happy customers.