Journey into mocks #2

I realize that if I’m going to continue this journey – see here – I’ll have to approach it piecemeal, or it won’t ever happen. I will begin by commenting on things in the “Endo-Testing: Unit Testing with Mock Objects” article, by Tim Mackinnon, Steve Freeman and Philip Craig, and we’ll see where this will take us. (I’ll assume that you have read this article.)

The biggest bother with mock objects, is that they force me to take a larger scope into consideration when developing something. The article’s suggested method, where you create mock classes for the objects that your testee (the object under test) will interact with, forces me to think not only about the new class I’m developing, but the neighboring classes as well. I find it essential to test-driven development (TDD) to be able to, when developing something new, ignore the parts of the problem that I know little about, and start with the things that are more obvious how to implement.

By taking on the more obvious things first, I learn more about the problem and possible design options, thus placing me in a better position to take on the things that weren’t obvious up front. If I have to consider a larger scope and create mocks for the related classes, I find that this stifles TDD. One major point with TDD is to let you ignore things and focus on the part you know enough about to start with. It’s about deferring design work up until the moment you are about implement something, with the motivation that the best way to learn is to implement.

To not stifle TDD, you have to resist the temptation of using mocks until you can’t come up with any alternatives. I have found that whenever I have the urge to mock, reducing the scope even further helps me to avoid mocking, somehow. Let’s say you’re developing a class that will need to interact with a database to retrieve a set of objects. You feel the urge to mock the not-yet-written database classes, which would force you to think about them as well. By reducing the scope by only setting the objects, with a set method in your testee, thus ignoring the database stuff, you can get on with your work.

Of course, you could create an interface called Database with one method called, for example, fetchEmployees(String name) and pass it to your testee. And then create a MockDatabase that implements the interface, with methods for setting the returned Employee objects. But doing this you have made assumptions about the neighboring classes, that in some cases might be too early to do.

If you want to mock anyway, I would suggest that you defer the creation of the full blown mock classes and initially only create a light-weight mock class, preferably as an inner class, or even anonymous inner class, if you program in Java. Hard code the expectations and return values to begin with. This technique could be called “mocking in place”. Once you have two or more “in-place mocks”, you can extract them into their own mock class, conforming to the format suggested in the article. But not any sooner.

This will have to do for the first installment of this series of posts. My daughter needs attention right now. Oh, and do mail me at mocks@tesugen.com if you have anything to say about this.

The above was posted to my personal weblog on June 30, 2002. My name is Peter Lindberg and I am a thirtysomething software developer and dad living in Stockholm, Sweden. Here, you’ll find posts in English and Swedish about whatever happens to interest me for the moment.


Related posts:

Posted around the same time:

The seven most recent posts:

  1. Tesugen Replaced (October 7)
  2. My Year of MacBook Troubles (May 16)
  3. Tesugen Turns Five (March 21)
  4. Gustaf Nordenskiöld om keramik kontra kläddesign (December 10, 2006)
  5. Se till att ha två buffertar för oförutsedda utgifter (October 30, 2006)
  6. Bra tips för den som vill börja fondspara (October 7, 2006)
  7. Light-Hearted Parenting Tips (September 16, 2006)