Guest blog byStephen Ebichondo
The second session of .NET user Group Meet up we shall look at Integration testing which is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis
In many of the projects that we have worked on, the application we’re building needs to integrate with a back-end system or a web service layer that is maintained by a third party or by another team. In these cases, we shouldn’t assume we’ll have the ability to ensure that the other group has set up an automated test bed to verify regression.
Whether you're a tester or a developer, this session is for you. If you would like to speak at this event kindly contact me email@example.com