On 11 Apr 2009, at 23:59, Brandon Olivares wrote:
I've read of complaints that mocking can make the specs very
brittle, in
that if the method is changed at all, it will break the specs, even
if the
behavior remains the same. Do you find this to be the case? How do
you deal
with this if so?
I've found the opposite more often - changing the specs of one side of
an interaction leaves them passing, but the code no longer joins up.
You should, after all, usually be changing the specs first.
Recently, I've been leaning towards limiting mocks to points in the
code where either the number of logic branches starts to explode (read
- you've got `if` statements), or the interactions are more important
than the implementation (ie - you're more likely to change how the
other object works than what it/its interface is). Basically, I use
them when it makes life easier*. These are rules of thumb to me right
now, so I probably couldn't explain well what I mean, although I'm
sure I should try.
I like to view it as a sliding scale...
Pure mock specs Pure integration specs
|--------------------------------------------------------------|
Lead more directly to good OOP Allow rapid hack-solutions
Force you to think things through Encourage experimentation
Fragile Sturdy
Fast to run Slow to run
Localised failure errors Vague failure errors
High risk of false positives High risk of whack-a-mole debugging
Or at least those are how I find them.
I think I need to sit down some time and think through more formal
strategies to choose when to use mocks.
Right now I'd say, use mocks aggressively, work through the problems
you find (which tend to highlight poor OO design), learn the design/
refactoring tricks, then take a step back. But make sure you've got
some layer of integration spec (maybe Cucumber) above mocked specs,
and make sure you don't give up *before* you feel like you've tamed
mocks. Ignoring either of those could leave you thinking they are a
bad tool that cause brittle specs, when actually they are a very
powerful tool, just hard to use at first*.
Ashley
* some things that eventually make like easier seem to make it harder
initially
--
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran
http://aviewfromafar.net/
http://twitter.com/ashleymoran
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
