[rspec-users] Mocks? Really?
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.
More information about the rspec-users