named references for test fixtures

Courtenay : October 16th, 2006

Do you hate maintaining references in fixture files? I know I do. Well, as mly said in #caboose, "better get yourself a new pair of underoos, because your life is about to get one hell of a lot easier". h2. fixtures: quit yer whinin' and do somethin' about it I was implementing multi-domain user accounts for an app and got sick of looking up the associated IDs for my fixtures, like ~ 

# users.yml
joe:
  id: 1
  name: joe 
  domain_id: 2
mary:
  id: 2
  name: mary jane
  domain_id: 1

# domains.yml
first:
  id: 1
  name: first.com
second:
  id: 2
  name: second.net
Why do we need this horrible duplication of effort and code when we already have named fixtures? A few lines of code later, and we can execute our yaml like thus, with the name of the associated fixture in the foreign key slot. 

# users.yml
joe:
  id: 1
  name: joe bob
  domain: :first

mary:
  id: 2
  name: mary jane
  domain: :another
*domain_id: 1* becomes *domain: first*, the IDs get filled in automagically, and a rake db:fixtures:load and script/console later, we can do 

User.find(1).domain.name
=> first.com
User.find(1).domain_id
=> 1
User.find(2).domain_id
=> 2
Now this is all very opinionated software, so it doesn't 'do' clever things like looking up your model for associations (yet). I'm still working on the code and associated tests, but you can be sure this will be headed for core at high velocity. Updates to follow. Dump your preferred syntax in the comments, yo.
Posted by Courtenay Filed in

19 Responses to “named references for test fixtures”

  1. Dr Nic Says:
    October 16th, 2006 at 10:09 PM

    I like it a lot.

  2. Luke Redpath Says:
    October 16th, 2006 at 11:04 PM

    Much much better than the usual way of doing things.

    I still hate YAML fixtures though – hiding your fixtures away in other files, away from your tests, is detrimental to test clarity (not to mention speed in the case of rails fixtures) IMO. These are two things I’m not willing to sacrifice for no (obvious) benefit.

    Good work though! Its still an improvement for those who insist on using them ;)

  3. court3nay Says:
    October 16th, 2006 at 11:16 PM

    http://dev.rubyonrails.org/ticket/6424

  4. bryanl Says:
    October 17th, 2006 at 12:26 AM

    I like this. It sure goes along way in producing readable YAML.

  5. Daniel Von Fange Says:
    October 17th, 2006 at 12:29 AM

    I’m crying. I want it so badly.

  6. Chris Says:
    October 17th, 2006 at 03:10 AM

    patch++

  7. josh susser Says:
    October 17th, 2006 at 04:28 AM

    This is good stuff. I’ve been wanting exactly this for ages. It seems like you’re doing the fixtures equivalent of what I did with dynamic finders. If you need to steal any code for navigating association reflections from there, feel free.

    Something to keep in mind is polymorphic belongs\_to refs also need a \_type field, and it would be nice if that could be filled in as well. That’s where I gave up in hacking dynamic finders because the code in AR::Base was so ugly.

  8. court3nay Says:
    October 17th, 2006 at 06:18 AM

    this code only looks in the raw data returned from the fixtures :foo, :bar statement and not in the model. I like it that way since fixture data is not strictly tied to your app but rather, to your db

  9. josh susser Says:
    October 17th, 2006 at 06:32 AM

    Well if you’re not peeking at the model (which is fine), then maybe you can provide for the \_type field on polymorphics another way. YAML syntax is a bit ugly, but maybe something like:

    joe:
  id: 1
  name: joe bob
  address: {id: :home, type: :shipping_address}

    That would look in the shipping_addresss fixture file for entry home, and set the \_type field to ShippingAddress.

    Probably overkill, though.

  10. csm Says:
    October 19th, 2006 at 07:33 AM

    shouldn’t the second code be:

    mary:
  id: 2
  name: mary jane
  domain: :second

    Instead of :another, if you are referring to this in the domains.yaml:

    second:
  id: 2
  name: second.net

    Yes?

  11. court3nay Says:
    October 21st, 2006 at 06:59 PM

    yeah, the example was both contrived and made-up on the spot.

  12. shan3_v Says:
    October 24th, 2006 at 08:51 AM

    Nice… can’t believe no one thought of it before.

  13. Matt Says:
    October 29th, 2006 at 06:50 AM

    Pleeeaaaseee get this patch in!

    I’ve been trawling Google for information on how to use fixtures like this, and drawing a blank. I even went as far as putting:

    <% fixtures :users %>

    Into other YAML fixtures and then using:

    user: <%= users(:bob) %>

    Which, of course, does not work! Though implementing your patch that way, rather than just using keys alone might be more ‘rails like’ and not lead to naming conflicts?

  14. peterpunk Says:
    October 31st, 2006 at 03:13 PM

    Hi! based on http://dev.rubyonrails.org/ticket/6424 I made a modification to non edge fixtures.rb to support naming references with reflection too so your class attribute can have other name than the singular name of the table :-) (I have this cases on complex models), I will publish it on my blog as soon as possible.

    P

  15. Giatas Says:
    July 9th, 2007 at 03:51 PM

    Cool!

  16. Milos Says:
    July 9th, 2007 at 07:34 PM

    interesting

  17. Yannas Says:
    July 9th, 2007 at 09:55 PM

    Nice!

  18. Ahmed Says:
    July 10th, 2007 at 02:28 AM

    Nice…

  19. Titos Says:
    July 10th, 2007 at 07:03 AM

    Interesting…

Sorry, comments are closed for this article.