[rspec-users] Mocks? Really?

Francis Hwang sera at fhwang.net
Sat Dec 29 17:46:51 EST 2007

I don't know if anyone else will find this thought useful, but:

I think different programmers have different situations, and they  
often force different sorts of priorities. I feel like a lot of the  
talk about mocking -- particularly as it hedges into discussions of  
modeling, design as part of the spec-writing process, LoD, etc --  
implicitly assumes you want to spend a certain percentage of your  
work-week delineating a sensible class design for your application,  
and embedding those design ideas into your specs. At the risk of  
sounding like a cowboy coder I'd like to suggest that some situations  
actually call for more tolerance of chaos than others.

I can think of a few forces that might imply this:

- Team size. A bigger team means the code's design has to be more  
explicit, because of the limits of implicity knowledge team members  
can get from one another through everyday conversation, etc.
- How quickly the business needs change. Designs for medical imaging  
software are likely to change less quickly than those of a consumer- 
facing website, which means you might have more or less time to tease  
out the forces that would lead you to an optimal design.

In my case: I work in an small team (4 Rails programmers) making  
consumer-facing websites, so the team is small and the business needs  
can turn on a dime. From having been in such an environment for  
years, I feel like I've learned to write code that is just chaotic  
enough and yet still works. When I say "just chaotic enough", I mean  
not prematurely modeling problems I don't have the time to fully  
understand, but still giving the code enough structure and tests that  
1) stupid bugs don't happen and 2) I can easily restructure the code  
when the time seems right.

In such environment, mocking simply gets in my way. If I'm writing,  
say, a complex sequence of steps involving the posting of a form,  
various validations, an email getting sent, a link getting clicked,  
and changes being made in the database, I really don't want to also  
have to write a series of mocks delineating every underlying call  
those various controllers are making. At the time I'm writing the  
spec, I simply don't understand the problem well enough to write good  
lines about what should be mocked where. In a matter of hours or days  
I'll probably end up rewriting all of that stuff, and I'd rather not  
have it in my way. We talk about production code having a maintenance  
cost: Spec code has a maintenance cost as well. If I can get the same  
level of logical testing with specs and half the code, by leaving out  
mocking definitions, then that's what I'm going to do.

As an analogy: I live in New York, and I've learned to have semi- 
compulsive cleaning habits from living in such small places. When you  
have a tiny room, you notice clutter much more. Then, a few years  
ago, I moved to a much bigger apartment (though "much bigger" is  
relative to NYC, of course). At first, I was cleaning just as much,  
but then I realized that I simply didn't need to. Now sometimes I  
just leave clutter around, on my bedside table or my kitchen counter.  
I don't need to spend all my life neatening up. And if I do lose  
something, I may not find it instantly, but I can spend a little  
while and look for it. It's got to be somewhere in my apartment, and  
the whole thing's not even that big.

Francis Hwang

More information about the rspec-users mailing list