[rspec-users] Dealing with dependent data

Mikel Lindsaar raasdnil at gmail.com
Wed Jun 25 22:38:22 EDT 2008


On Thu, Jun 26, 2008 at 12:18 PM, Christopher Bailey
<chris at cobaltedge.com> wrote:
> The other thing I'm finding a lot is that I have a lot of the same
> needs for this fixture type data between my regular RSpec examples
> (model tests mostly, as I'm going light on controller and view tests
> and mostly doing stories) and my RSpec stories.  Are folks using say a
> single helper/factory to generate fixture data for both?  I guess I
> only just though of sharing it between them now, as there really is no
> technological barrier to doing so, although in my examples I do tend
> to leverage mocks and stubs when I can, but stay strictly "real" with
> stories.

For me, I tend to use a Model.build_valid pattern to create objects
required in my controller view or model specs and then only really
stub required behaviour... sort of like cherry picking stubs.

So I wouldn't stub the 'name' method on a person, instead, I would
create a valid person with the name I need.  But I would stub that
'save' returns 'true' or something of the like as I need to ensure a
particular execution path.

This arguably makes specs more brittle, but for me, finding and fixing
failed dependencies as soon as possible is better than having to
manually ensure that every method being called in a view is covered
elsewhere by a spec... and in changing a spec later, I get instant
feedback on if I have a regression failure elsewhere.

The other drawback you have with fixture data in stories is that they
are by definition an artificial state.  It is not guaranteed that the
state you create with fixtures could be reproduced by your code.  Only
through your code executing can you find the relevant states and you
might introduce an arbitrary in your fixture data that creates an
impossible state allowing your specs to pass.

So I ban fixtures in stories in my team for that reason.  Anything you
need in a story needs to be encompassed in the Given of that story and
the story needs to be able to be read in isolation with all
requirements visible, see my blog post on "Being clever in specs is
for dummies" at

http://www.lindsaar.net/2008/6/24/tip-24-being-clever-in-specs-is-for-dummies

For more on what I mean about that, the example is mainly for a
describe BDD block, but it applies equally well to a story.

Regards

Mikel


--
http://lindsaar.net/
Rails, RSpec, Puppet andLife blog....


More information about the rspec-users mailing list