Summary 137

Use a stub only for faking return values into the program under test, or to throw exceptions. Don’t verify that methods were called on stubs. Use a mock only for verifying that some method was called on it, but don’t use it to return values into your program under test. If you can’t avoid this situation, you should probably be using a stub and testing something other than what the mock object receives.

Don’t repeat logic in your tests.

If you’re asserting that some calculation is correct in your code, make sure your test doesn’t repeat the calculation in the test code, or the bug might be duplicated and the test will magically pass.

Don’t use “magic” values.

Try to always use hardcoded, known return values to assert against production code, and don’t create expected values dynamically. That would significantly increase the chances for an unreadable test or a bug in the test.

Overspecification is a common form of test abuse. Make sure you keep your eyes on this by doing frequent test reviews with your peers.

5.12 Summary

Dynamic mock objects are pretty cool, and you should learn to use them at will. But it’s important to lean toward state-based testing (as opposed to interaction testing) whenever you can, so that your tests assume as little as possible about internal implementation details. Mocks should be used only when there’s no other way to test the implementation, because they eventually lead to tests that are harder to maintain if you’re not careful.

Learn how to use the advanced features of an isolation framework such as Rhino Mocks or Typemock Isolator, and you can pretty much make sure that anything happens or doesn’t happen in your tests. All you need is for your code to be testable.

You can also shoot yourself in the foot by creating overspecified tests that aren’t readable or will likely break. The art lies in knowing when

138

CHAPTER 5

Isolation (mock object) frameworks

to use dynamic versus handwritten mocks. My guideline is that, when the code using the isolation framework starts to look ugly, it’s a sign that you may want to simplify things. Use a handwritten mock, or change your test to test a different result that proves your point but is easier to test.

When all else fails and your code is hard to test, you have three choices: use a “super” framework like Typemock Isolator, change the design, or quit your job.

Isolation frameworks can help make your testing life much easier and your tests more readable and maintainable. But it’s also important to know when they might hinder your development more than they help. In legacy situations, for example, you might want to consider using a different framework based on its abilities. It’s all about picking the right tool for the job, so be sure to look at the big picture when considering how to approach a specific problem in testing.

That’s it! We’ve covered the core techniques for writing unit tests. The next part of the book deals with managing test code, arranging tests, and patterns for tests that you can rely on, maintain easily, and understand clearly.

Part 3

The test code

his part of the book covers techniques for managing and organizing T unit tests and for ensuring that the quality of unit tests in real-world

projects is high.

Chapter 6 first covers the role of unit testing as part of an automated build process, and follows with several techniques for organizing the different kinds of tests according to categories (speed, type) with a goal of reaching what I call the “safe green zone.” It also explains how to “grow” a test API or test infrastructure for your application.

In chapter 7, we’ll take a look at the three basic pillars of good unit tests—readability, maintainability, and trustworthiness—and look at techniques to support them. If you only read one chapter in the book, this should be it.