In a room full of architects, no two will agree about their exact job description, as the joke goes. In a similar vein, someone in our team had a refreshing solution to another persistent bone of contention: how do you define an integration test? Don’t try to reconcile differing opinions and just stop using the term altogether. I liked it very much. Rather than think of unit and integration tests, it’s more helpful to distinguish between tests that validate code versus ones that validate public interfaces and recognize that within each category the scope varies for each individual test.

Here’s the first confusion that the word ‘integration’ throws up. Is it the integrated parts we target, or their points of integration? The first approach checks that parts cooperate and fulfill (part of) the implementation of some business functionality, for example submitting a new order and making sure that it is validated and saved. The latter category is only about checking contracts. What exact messages do we expect component A to receive and how should it react? Older readers may be reminded of WSDL and XML Schema. Not popular anymore, but still around in many enterprises.