Object Interactions

One important feature of object-oriented programs is that the actual behavior of the system is determined by the interplay of many instances and not by single objects. However, classic unit tests are limited to checking the isolated behavior of a program unit, moving the test of the units' interplay to the so-called integration tests. Procedural integration tests focus on the syntactically correct use of the interfaces and verification of side effects. Today, these tasks are assumed by modern IDEs or data encapsulation, respectively. For this reason, McGregor and Sykes suggest the new term to emphasize the shift of the test focus to the interplay of objects. McGregor and Sykes distinguish between two main types of interaction tests:

Although interaction tests are no longer unit tests on a class level, they are still indispensable for the correct behavior of our larger units. Experiences gained with object-oriented systems in the testing community contradict the hope that the correct interplay of our objects can be ensured solely by acceptance tests on a system level. When the distance between the test interface and the tested class becomes too big, too many errors in the components no longer reach the surface; they will be "hidden," but can still come up again under slightly modified circumstances.

For this reason, as developer-testers we won't be able to avoid different types of interaction tests. [] Indeed, several of our previous test efforts were oriented to the interplay of two objects. The fact that interaction tests are important parts of a test suite should not tempt us to test some objects only indirectly through other collaborating objects. On the other hand, testing a class in isolation is not sufficient to check the interplay of objects. We always have to keep an eye on the drawbacks inherent in inter-unit tests: increased cost of changes and refactorings. []For this reason, there are also proposals to rename XP unit tests mobility tests or build tests.