About
Exploring Solution Spaces, Keith Ray's blog on Software development and other topics.
Send comments to:
keithray@mac.com
| For Agile Training, eLearning, or Coaching contact: |
| Industrial Logic, Inc. |
| 866-540-8336 (toll free) |
| 510-540-8336 (Berkeley, California) |
| Links |
| xpminifaq |
| Résumé |
| “Adopting XP” Article 2002 (pdf) |
| “ Refactoring” Article 2006 |
| AYE Conference |
| Lucien W. Dupont |
| Elisabeth Hendrickson |
| Johanna Rothman's Managing Product Development |
| Brian Marick's Exploration Through Example |
| Esther Derby's Insights You Can Use |
| Laurent Bossavit's Incipient(thoughts) |
| Dale Emery's Conversations with Dale |
| Martin Fowler's Bliki |
| Creating Passionate Users |
Archives
Subscribe
RSS Exploring Solution Spaces XML
2006.Oct.31 Tue
Mock Objects used in Test-Driven-Development are "fake" objects that return specific values, and assert that calls are made with correct arguments and in the correct order. Avoid them. Mocks make your tests more fragile and more tightly-coupled. And at the same time, they reduce the integration-test aspects of TDD. They make your tests larger and more complicated and less readable.
Mocks reduce your tests robustness. If you change an object's API, a mock object's API may not change, making your tests out-of-date with respect to your non-test code. This depends on whether you are using a Mock-generating framework, or not, and how your mock object is implemented or how the Mock-generating framework is implemented.
In TDD, you normally write a test, write some code in a target class/method that passes the test. The third step is refactoring. That's when you can do "Extract Method"/"Extract Class" Refactorings to start creating other classes that cooperate with your target class (those extract classes may be "stub" classes at first, see below). Test-Driving with Mocks inverts that order: you create your target class and a mock class up-front, and plan on how they interact, instead of evolving that interaction in TDD's refactoring steps. You pre-judge the class design rather than evolve it.
Mocks are tool for decoupling, and I do sometimes use them. I limit my use of Mocks to those situations where the real object will not reliably do what I want. Examples: simulating errors in writing a file; simulating connections with a remote server; simulating errors from remote server. Often with libraries that were not designed with TDD in mind, such as the TWAIN libraries used for controlling scanners and implementing scanner-drivers.
Stubs are objects with hard-coded return values, but without the assertion-behavior that mocks have. Sometimes I do create stub objects during TDD, and later I focus on test-driving the stub-object class into being a "real" class. The existing tests (for code that is using those stub objects) help insure that I don't break anything that depends on that stub-becoming-real class. If a Mock generated from an interface was used instead of Stub, there would be a disconnect. My "real" class's return values (and implied behavior) could diverge from the mocked return values and nothing but code inspection or failing acceptance tests would tell me. I prefer to have failing tests tell me when behavior is changing. Remember change-detectors?
Mocks are tool, and a tool can be over-used or misused. I think for many people new to TDD, mocks are their new hammer, and every problem is treated like a nail, even when a saw or a screwdriver would be more appropriate for the situation.