The Fundamentals of Integration Testing

The Fundamentals of Integration Testing

Integration testing is the stage in which a software application is tested entirety, using a fully functional version of all the dependent components. Whereas in code dependencies development, unit evaluations are spelled outside, code dependencies in the integration testing phase are fully functional. Integration testing is the area where the code and all its parts are confirmed to work based on expectation. Integration testing is where everything comes together. It is the area where all the functionality of the program is tested.

Understanding the Scope of Testing

The very first order of business in Integration Testing is establishing the border of the code under test. By way of example, if the intention of the Integration Test is to test the performance of consumer interaction with a program, the boundary of testing is going to be the software Graphical User Interface (GUI). That testing boundary will be the program's web pages viewed via a browser. In the event of native programs running on a mobile device or desktop computer, the border is the program GUI directly on the operating system.

When Integration Testing an API, the border will be endpoints published by the given API. The boundary of Integration Testing for a component that's constituent dependencies would be the resources and processes of the component if the part is an object-oriented binary. If the part is an executable file or script, then the boundary of Integration Testing is the command-line invocation of the script including its own parameters.

Types of Integration Testing:

Black Box Testing

In Black Box testing, the way the code works is hidden from the evaluation. The only things apparent is the data that goes into a component and the information that comes out. Thus, integration evaluations will send in some data and confirm the output adheres to the expectations defined in the test program. Thus, a whole lot of thought needs to be given to the width of testing making sure that all good and bad behaviours are expected.

Gray Box Testing

Nonetheless, besides providing input and assessing output, in a Gray Box situation the machine emits information during the evaluation that may also be gathered and examined to verify that

behavioral expectations are met. For instance, system logs might be considered as information important to the Integration Test. Thus, log info needs to be gathered and the evaluation plan will have to integrate log data together with test result data.

In Gray Box Testing input and output data is evident, but also data emitted and recorded by constituent components can be collected for analysis.

By way of example, Interaction Testing can key to a correlation that traverses all component logging to gather information to confirm that all elements in a transaction behaved as anticipated.

White Box Testing

Thus, an Integration Test will reveal not only data in and data out but also the behavior of all of the code in most of the components in play. For example, a White Box Integration Evaluation can report that the code protection of all of the components in play as well as query behavior against applicable datastores, to name a few items.

White Box Integration Tests have access to verify each one of the parts relevant to the artifact under evaluation.

Conclusion

Integration Testing is a critical part of this Software Deployment Lifecycle. Integration Testing picks up where unit testing leaves off. Whereas a unit test will mock out all but the important behavior of the device under evaluation, normally a function, Integration Testing expects fully functioning software at each level.