Exploring integration testing in the Agile development lifecycle

How does integration test fit into an Agile development lifecycle?

The term “integration test” means different things to different people. Many people use the term “integration test” when they’re actually referring to “component tests.” Gerard Meszaros defines “component tests” as tests that verify the architectural decisions made by the development team. These tests are written after customer-facing tests which define system behavior, and before unit tests which verify the smallest units of code. Unlike customer-facing tests, component tests don’t need to be readable by business experts, and can be automated in the same framework as the unit tests.        

Some people use the term “integration testing” when referring to testing multiple layers at the unit level together – business logic, database access, presentation layer. This is in contrast to true unit tests, which run in isolation, having components for other layers mocked, faked or stubbed out. Programmers in Agile projects practice test-driven development, writing a small, isolated unit test, then the small bit of code to make that unit test work, then the next small unit test. They also need to confirm that the various layers communicate with each other properly, so they also write integration tests. Some people call these “contract” tests, because they verify the contract between two units of code, defining what information is exchanged. Because these tests are generally much slower than unit tests, they may run in separate automated test suites in the continuous integration process.

“Integration testing” may also be used to refer to end-to-end system testing, verifying from the user perspective that all parts of an integrated system work together as expected. This is often seen as an activity to be done just before release, but as Gerard Meszaros points out, it really should be done up front. However, you may be working on an application that is somewhat self-contained but needs to integrate at a high level with other systems. I once worked on a team where we were delivering the shopping website for a large telecom. Our site had some integration points with other applications used by the telecom and its customers. Our own test environment didn’t include these other systems, we had to schedule in time on the full integrated test environment. We worked around this by completing two or three iterations of production-ready user stories, then spending an iteration testing with other teams in the full integration test environment, then starting another release cycle. It wasn’t an ideal solution, and required extra people on the team to help communicate with the other teams, but it worked.