I’ve never liked mock objects. At best, they’re a necessary evil. At worst, a meaningless “test” that overspecifies the code under test.
I tweeted back that “I’m finding mocks that overspecify the code under test are a sign that I’m making code that doesn’t express intent well.”
Here’s something of what I mean by that. Suppose I want to describe, in English, what it means for a function to make an X509 certificate from some Base64-encoded text and store it in a particular file. The method is part of a
Contact object. Here’s the description:
Contacts, as you know from an earlier description [test], are created with a pile of information contained in a hash. One bit of relevant information is the
:organization. There are also some Base64-encoded keys. Let’s pick one at random, call it
In order for the
Contactto create and stash the certificate, it collaborates with two objects. One of them is the
:certificate_maker; the other is a
:folderthat knows how to stash info into a named file. The
:certificate_makeris hardwired into the
Contact, but the
:folderis passed in.
In order to stash
:stash_this_keymethod has to do two things:
It has to hand the (Base64-decoded) certificate info (the key) to the
:certificate_maker, which will return some sort of encoded gibberish.
:folderhas to be told to stash the gibberish into one of its files. The filename is of the form organization-name.a_key.pem. (The organization name is made according to the rules I already told you for sanitizing organization names.)
Here’s the actual test. I think you can see how it parallels my description:
It does specify implementation. Most importantly, it says that there should be a completely separate
CertificateMakerobject. That’s a good thing. Had I not been committed to mocking, I would have been tempted to just copy-and-paste the code I was working from, which looked something like this:
Had I done so, I would have likely never bothered to figure out what sort of magic thing
"openssl x509 -inform der"does. As it was, I had to know enough to make a decent class and method name, meaning I had to learn my domain.
Given that the hard part of object-oriented design is figuring out what objects should exist and how they should interact, something that forces me to think harder about interactions and responsibilities might well be a win.
That said, there’s a constant temptation to make the implementation “incidental”, to describe what does happen in this implementation rather than what ought to happen in any reasonable implementation that fits within the, uh, conceptual domain of the program. For example, Ruby already has abstractions for file systems: the
Fileclasses. If my mock tests for
Contacttalked about how
Dirare called, … that would be bad. Instead, test expressiveness forced me to condense down everything Ruby lets me do into the more limited idea of a
PreferredFolderthat knows how to “stash” strings.
I grant you that I still feel like I’m going overboard when I start with 27 lines of sample code and later discover I’ve got a
CertificateMaker— all just to snatch something off the network, convert it, and stuff it into a file. Certainly, I’m going slower than I could (in the early part of the project), but I don’t necessarily think that’s a bad thing. I trust that it’ll keep the cost of change curve flatter — though my trust in myself might be misplaced. Wouldn’t be the first time.