Top Ten Reasons to use Mock Objects in your Unit Tests

Top 10 reasons

1. Complete Unit Test Isolation
2. Top Down Development
3. (Almost) Automatic Dependency Inversion
4. Makes 100% code coverage approachable
5. They make your unit tests run really freakin fast.
6. They make your unit tests run really freakin fast.
7. They make your unit tests run really freakin fast.
8. They make your unit tests run really freakin fast.
9. They make your unit tests run really freakin fast.
10. They make your unit tests run really freakin fast.

That last one is huge. In my experience, a slow test suite is seldom run manually. A fast test suite is run much more often. Running the suite more often means you introduce less errors. If you haven't tried using mockobjects in your unit testing, you need to give it a good go-round. And by good go-round, I don't mean spending an hour or a day trying them out. You need to spend at least a couple of weeks working with them before you can start to grok it. Fowler chats about them a bit here, and as usual, it's well worth the read. As Fowler points out, the big downer is the implementation coupling. You are designing a unit to work in isolation, though, and white box testing is a vaild approach. You just need to understand the tradeoffs. Fowler highlights most of the top 10 list in his discussion, but fails to talk about the psychological impact of a truly fast test suite.

These days, I tend to break my tests into pure unit tests using mock objects when it makes sense, functional tests that are, in fowler's terminology, basically state-based and end-to-end, and integration endpoint tests that test [my system's abstraction of] interfaces to external systems. I run the unit and integration tests frequently, and the functional less so, e.g. before check-in. If I have been a good boy and implemented continuous integration, then everything is, of course, run in the context of that.

Then of course, there are acceptance tests, but that is a different story and a different day.

Comments

[Paul Holser]

Good man. You end up with designs that are composed of smaller, more focused parts, too. Imagine how much more pleasant administering customer information for a closing services division might have been with such tests being developed; run all the time via a CI loop....