Unit testing tests individual units in isolation. Dependencies between units are abstracted, usually by interface. The interfaces create a contract to which both the dependent and the dependency adhere, but code rarely has no side effects. Even in previous chapters, we’ve seen side effects from using streams. A stream’s position and whether it’s open, closed, or disposed can be changed by any code that touches it. Changes to a database while your code is running may cause an insert to fail or an update to be overwritten. Unit testing isn’t enough. We also need to test how units work together—that is, run integration tests.
DEFINITION
The clearest definition of integration tests I’ve found comes from Martin Fowler. (Read the article at http://mng.bz/MZ2D.) The article states, “Integration tests determine if independently developed units of software work correctly when they are connected to each other.” Fowler goes on to distinguish between broad and narrow integration tests, the former involving many active modules and the latter using mocks or fakes to test a limited set of interactions.