Types of Integration Testing

Stages of Development Testing

The need for testing a new bit of software before it's released to clients is as outdated as software development itself. But, it is typically left up to the respective organization to ascertain what kinds of testing need to get performed, and how thorough the testing should be.

The testing methodology and processes can be left to individuals supporting each individual development group inside an enterprise, causing situations where the right hand is unaware of what the left hand is doing. This will last until at a certain point, things go horribly wrong. Then management is required to step in, and require more successful testing. Developers then struggle to boost test efficacy using their limited resources. The result is a continuous balancing act between spending enough hours to test efficiently without missing deadlines.

Testers are frequently looked at as only a second line of defense to capture issues the developers overlook. Because of this mindset, the sad reality of testing is that when funds become strained, it's often the first area to be trimmed, or in many cases entirely cut. With this reality in mind, we are always on the lookout for ways to improve testing efficiency, which we take a look at in this article.

Who Carries out Integration Testing

When people typically think of testing enterprise scale applications, they will typically envision a set of dedicated testers, hammering the newly developed software using a barrage of tests to expose its flaws and weaknesses. Even though an enterprise DevOps team might have a team of testers, they're not necessarily the only ones conducting tests.

Purpose of Integration Testing

Assessing every stage of testing would require a much longer post, so here we will focus mostly on Integration testing in a DevOps atmosphere. We'll begin with a simplified definition.

Integration Testing: The testing of a part or module of code to ensure it integrates properly with other components or modules of code.

Integration Testing Modules

Once we speak about incorporating a single component with another, we are referring to making certain the two segments fit together properly and communicate information right between each other. This second module then means this, and generates the search parameters to ship on to the database via JDBC.

The challenge with integration testing is that if you have multiple developers simultaneously developing multiple modules, you can not examine just how two or more modules incorporate together until each of the modules are prepared... or will you? There are various procedures of integration testing that could be helpful when testing integration of various modules of a item.

Types of Integration Testing

Big Bang Testing -- Using the example in the image above, your new product under development was divided into six modules to maximize programmer tools. With Big Bang testing, then you would have to wait for all six modules to be completed before starting integration testing.

This kind of testing may be equally price and resource intensive, because the reality is that some modules will be completed long before others. Causing some of your developers to be unproductive while waiting until the previous module is completed, then scramble again if it's finally time to check. Then when an issue is discovered, it's far more difficult and time intensive to monitor the issue down to the specific segment of code that needs to be fixed.

Incremental Testing --

With our same example of six complete modules for a given product, when two connecting modules are finished, they can be incorporated together and tested to make sure that the information being communicated is exactly what is expected.

While this type of testing is obviously more efficient, there's another sort of Incremental testing that is even more effective yet. When development of this Search function is finished, instead of waiting for module #2 to be completed (to interpret the search criteria into a JDBC database query) the programmer can produce a Stub to check the Search function against. Testing against stubs and drivers does not mean that further issues won't arise because modules are additional integrated and further examined; difficulty code is identified and corrected in effective phases, instead of in one closing panicked rush.

Stub -- A Stub is a small section of code which simulates the reaction of the linking lower level module. Using our example from the preceding diagram, it would Get the user defined search criteria from the Search module and provide a straightforward pre-defined Reply, or collection of responses which would mimic what might be sent straight from the

Driver – A Driver is comparable to a Stub, however, it simulates the data response of a linking higher level, or parent module. Using our example from the diagram above, if the middleware component was finished first, a motorist could simulate the sending of user defined search criteria, and also the receipt of their search results.

Top Down Testing – In a DevOps surroundings, Incremental testing is typically the preferred way of analyzing because it offers the most efficient use of development and testing resources. Tests can be performed on a module the moment development on it is completed. Programmers can normally test it very fast contrary to their stubs and drivers, making any necessary adjustments to the code to the module immediately.

Bottom Up Testing –

This kind of testing involves testing the high level or parent module(s) first, then analyzing lower degree or child modules as development is completed and they're integrated. Stubs are used to simulate the data reaction to lower level modules until they are finished and integrated.

Lower level modules are analyzed first to ensure that the individual modules are functioning correctly before they are incorporated with their parent module. Drivers are utilized to simulate the parent's modules information reaction until the development of the parent module has been completed and incorporated.

I am a technical content writer at testingxperts, interested in writing articles on the latest IT related topics.