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

TRIANGULATION OF TESTS

The “happy path” is always easy to test. If your unit tests stay on the happy path or tests one set of input values that fall within the middle range of the possible inputs, they are not telling you the whole story. Actually, it's worse than that: They lie to you. They tell you that your code satisfies the business needs and have a high degree of quality. This isn't true.

The problem is that all input is evil. When you don't build tests that probe the boundaries of your code and go beyond, you are essentially crossing your fingers and hoping that the users never push the boundaries of your application. Users just want software that works. They don't understand concepts of memory size, out-of-bounds errors, null object exceptions, or the problems that arise from using values that are either higher or lower than the range of values your code expects. And they shouldn't have to; your application should worry about these issues.

When writing unit tests, be sure they explore the boundaries of what your method expects. If your method expects a value between 1 and 10, write a test that passes in 5. Then write tests that pass in 1 and 10. Then write tests that pass in 0 and 11. Make sure that your code knows what to do with the unexpected. That was the point of the and_saving_an_invalid_item_type test class and its then_an_agrument_null_exception_should_be_raised test. I wanted to make sure that the ItemTypeRepository class would be able to handle the case in which ...