Integration testing should fit in like the stitches in a

Testing continuously ensures that the pieces fit together like stitches in a blanket.

In Integration Testing Is Core, we defined integration testing as testing in which components (software and hardware) are combined to confirm that they interact according to expectations and requirements. This ensures that the technical architecture decisions are correct. This is one definition of integration testing, but there are others. A second definition of integration testing is the tests needed to determine that components communicate or connect at a component-by-component level. Proponents of this second definition apply these types of tests as part of the build process either before or as part of unit testing. A third definition is as end-to-end testing, a form of system testing usually done late in development. Regardless of the variation, integration testing can be accomplished by building it into the cycle of daily builds.

Daily or continuous builds (preferably automated) are an efficient delivery vehicle for integration testing. The basic flow of configuration management that feeds the build begins when a code module is checked out, new code or code changes are written, and then the code module that was checked out is updated.  Once the developer has satisfied herself that the code meets its acceptance criteria (read Test Driven Development), it is checked back into the configuration tool adding to the project’s code base and then it will be “built.”  The build assembles all the bits and bytes into an integrated code base – an application. This new code base will be used for integration testing. However, if the process stopped at the build, the fact that the code fits together would at least show that the new code did not break the build at a basic level.  This very basic level of testing is valuable, however it is not true integration testing. In order to match any of the definitions of integration testing it requires combining daily or continuous builds with specifically defined test cases to ensure that the code not only fits together like Legos, but work together like an integrated circuit.  The integration test cases need to prove that the code fits together, communicates and performs as expected. In Agile projects, these test cases do not spring into existence as a single deliverable, but rather these tests build over the life of the project, sprint by sprint.  Integration testing ensures integration, as well as a form of systems testing for the changes that were added in earlier builds.

As code is written and added to the build, the integration tests need to be ready. Therefore as stories are formed, integration test cases need to be built. Successful execution of integration testing must be a condition of done.  When integration is built into a team’s natural flow and executed over the whole project life cycle, it satisfies all three definitions.