INTEGRATE EARLY; INTEGRATE OFTEN

When using TDD, classes and methods are developed based on tests. Specifically, they are developed based on the idea that the tests mirror the specifications and functional requirements. When you write enough code to make all the tests pass, your class and/or method meets all the specifications and requirements. Other classes, external resources, and other components of the application are mocked and stubbed to allow the code you are testing to be tested in isolation. The kind of testing ensures the quality of the individual classes and components.

Because of this concept of isolation, true TDD unit tests by definition guarantee quality only up to the edge of the current class or method. This results in a series of seams that exist between the classes, components, and external resources used by the application as a whole. These seams are defined by the interfaces provided by the various classes, components, and external resources. Even when an interface seems clear in its intent, problems can still arise when the time comes to join two or more pieces of software to form an application. You should ensure that these dependencies are mocked and stubbed correctly. However, it is still possible for errors and defects to be introduced. Perhaps the input being provided to a method isn't what was expected. Maybe a method's output is not what the consuming class wants. In many scenarios, classes, components, and resources are well designed and have well-written ...

Get Professional Test-Driven Development with C#: Developing Real World Applications with TDD now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.