What It Is, and What It Isn't
When the team designs the integration tests, they are much more likely to address the real weakness of the software. And if a particular test fails, there's a good chance that the team members will know exactly what caused it. In contrast, consider what would happen if the same defect were found two months later in a test cycle. A programmer would need to set up the environment again, trace through the code, replicate the malfunctioning behavior, and reverse-engineer and repair the underlying cause. He doesn't have the advantage that comes with having recently designed the tests to exercise specific code.
Integration testing is not a replacement for functional and regression testing. But it does give the team a relatively light-weight tool to help them evaluate whether or not the product is close to release.
In an agile environment, where there's little tolerance for long testing schedules, this kind of integration testing can be extremely valuable. Typically, code developed by an agile team will have extensive unit tests. However, unit tests typically verify only that individual objects function correctly. There is often at least a small gap in testing how those objects interact. This gap gets especially compounded when humans are involved. The reason for this is that unit tests must always run automatically and independently. Humans tend to string together behaviors that call upon many areas of the software. This is exactly the sort of condition that automated unit tests don't replicate. And many automated unit tests do not cover interface, but only the objects that interface is wired up to. By including an integration test at the end of every iteration, an agile team can deliver better code to their users.
But even an organization with a full testing process will benefit from developer-run integration tests. This integration practice makes an excellent addition to the exit criteria for the software development phase of a project with a "heavy-weight" software process. It catches defects earlier and can reduce the number of regression testing cycles, which will lead to shorter schedules. And, just as importantly, it can serve as a superior smoke test. Many teams use a subset of the system test cases as a smoke test that must be passed before a build can be accepted into testing. This practice will replace that subset with substantially different tests. Those tests will still verify that the build is ready to move forward in the process, but they have the advantage of being able to catch different defects than those that the QA team would have thought to look for. They provide wider coverage, which leads to higher quality. But most importantly, integration tests have the intangible benefit of giving the entire team--and not just the testers--a personal stake in the quality of the product.
