A parable about mocking frameworks
Somewhere around 1985, I introduced Ralph Johnson to a bigwig in the Motorola software research division. Object-oriented programming was around the beginning of its first hype phase, Smalltalk was the canonical example, and Ralph was heavily into Smalltalk, so I expected a good meeting.
The bigwig started by explaining how a team of his had done object-oriented programming 20 years before in assembly language. I slid under the table in shame. Now, it’s certainly technically possible that they’d implemented polymorphic function calls based on a class tag–after all, that’s what compilers do. Still, the setup required to do that was surely far greater than the burden Smalltalk and its environment put on the programmer. I immediately thought that the difference in the flexibility and ease that Smalltalk and its environment brought to OO programming made the two programming experiences completely incommensurable. (The later discussion confirmed that snap impression.)
I suspect the same is true of mocking frameworks. When you have to write test doubles by hand, doing so is an impediment to the steady cadence of TDD. When you write a statement in a mocking framework’s pseudo-language, doing so is part of the cadence. I bet the difference in experience turns into a difference in design, just as Smalltalk designs were different from even the most object-oriented assembler designs (though I expect not to the same extent).
January 24th, 2010 at 10:07 pm
Writing test doubles by hand has its own cadence. At least it does for me when I’m programming in Java and using refactoring tools. I use them to quickly generate interface implementations, one or two method inner classes, and builders for immutable types. I will often evolve production classes out of test doubles or make production classes flexible enough to be parameterized and used as test doubles. My test setups often contain a little test data and a couple of inner classes that implement just enough behavior to exercise the system under test. A lot of the time those inner classes are parameterizable so that a large set of test setups can be expressed as variations on a theme and a design change can be accommodated in the tests by altering a single base class. I’ve had bad experiences with having to do search-and-destroy missions for string constants in JMock tests when an interface changed. Later versions of the same tests shared testing infrastructure across a broader slice of the tests and were transparently updated by automated refactorings.
I’m looking forward to using JMock in order to bypass our DB layer, but I just can’t see why I’d want to use it on a day to day basis.
January 25th, 2010 at 8:27 am
[…] A parable about mocking frameworks (Brian Marick) […]