[rspec-users] Dealing with dependent data

Christopher Bailey chris at cobaltedge.com
Wed Jun 25 23:38:56 EDT 2008

I agree in general on fixtures, depending on how you define
"fixtures".  I never use the standard Rails fixtures, or any YAML
based fixture data.  I always generate my data from a factory or real
ActiveRecord call to create the object.  But, I still consider this
essentially "fixture" data, it's just created a different way.  It's a
trade-off.  If in my stories I had to walk through the view and create
the 30+ objects I needed just to setup my test, well, that test just
might not get written.  So to me, I use real ActiveRecord calls (via a
factory or helper of whatever kind), so that at least I know the model
creation is going through the real code, and is pretty close to the
path that the controller would do.  Then I test whatever it is I'm
testing that needs to have data like that.

For tests of new/create views, I of course actually create the models
via the view (I use Webrat), and such, so that is definitely real, and
that to me covers that case sufficiently.

On Wed, Jun 25, 2008 at 7:38 PM, Mikel Lindsaar <raasdnil at gmail.com> wrote:
> 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....
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

Christopher Bailey
Cobalt Edge LLC

More information about the rspec-users mailing list