Professional Test-Driven Development with C#: Developing Real World Applications with TDD

WRITING INTEGRATION TESTS

Writing integration tests is similar to writing unit tests. In fact, you will use a lot of the same frameworks to write your integration tests that you use to write your unit tests. The difference is that when you write integration tests, the goal is not necessarily to test the individual units of code. The goal of integration testing is to test the seams between the individual pieces of code. This means that the isolation rule that I talked about previously at length no longer applies. Well, that's not exactly true; the tests are isolated by the seam or seams they are testing, but they interact with several different classes and components — perhaps even an external resource. The goal of integration tests is to make sure that these different components all work together.

In practice, this means that at some point your integration tests will have to interact with some external resources. Your tests could read and write data to a database. Your tests could call a web service. Your tests could interact with files or folders on the hard drive. Because of this, it's important that you have access to an environment with test versions of all these resources over which you can exercise some measure of control. Before each test you need to reset the environment to a consistent pretest state. If you added or changed data in a database, you need to either remove it or put it back the way it was. If you call a web service, you need a test version of that service ...