Over the course of the last year or so I’ve been learning to play tennis. I’ve definitely improved from where I started (although it’s not hard to improve from disastrously bad). Last night I was playing and noticed that my serve had deteriorated somewhat. The solution to getting it on track was to go back to basics and practice doing the simplest and smallest movement that I could (ie not complicating the serve with excessive movements).
This morning I was reading Mock Roles, Not Objects and I was was reminded of my tennis experiences. It refreshed my thinking on the purpose and practices of TDD and mocking. There were several quotes from the paper that stood out for me:
- “Using TDD has many benefits but the most relevant is that it directs the programmer to think about the design of code from its intended use, rather from its implementation.”
- “Mock Objects changes the focus of TDD from thinking about the changes in state of an object to thinking about its interactions with other objects.”
- “Writing tests drives a framework to think about functionality. Mock Objects provides a framework for making assertions about those relationships and for simulating responses.”
Section 4 of the paper discusses Mock Objects in practices, detailing some guidelines for how to use them properly:
- “Only mock types you own”. Matt mentioned this one at our book club the other day in the context of skinning and wrapping APIs.
- “Don’t use getters”. Why? “Getters expose implementation, which increases the coupling between objects and allows responsibilities to be left in the wrong module. Avoiding getters forces an emphasis on object behaviour rather than state..”. I was taught not to use getters by Nick and I find myself discussing it often with each pair.
- “Specify as little as possible in a test”…”One of the risks with TDD is that tests become ‘brittle’, that is they fail when a programmer makes unrelated changes to application code.” This is on of the most common criticisms of TDD that I have heard from other developers. The paper goes onto say that the cause is that “…(the tests) have been over-specfied to check features that are an artefact of implementation, not an expression of some requirement in the object.” I’ve written tests that fall into in this category and I think it can be quite challenging to avoid doing so. Steve Freeman, one of the authors of the paper, blogged about this situation happening in a Coding Dojo earlier this year.
From time to time it’s useful to revisit papers like Mock Roles, Not Objects in order to remind yourself of the basics what you’re doing…. (and remember to watch the ball when playing tennis!)