Fixture Groups

March 29th, 2007

One of the things I like about working with Rails is test fixtures. However when the data model becomes more complex, the fixtures can become rather large. Worse yet, tests that require fixtures among two or more models feel clunky.

I wrote a plugin to help organize fixtures called fixture_groups.


  ./script/plugin install \
  http://source.elevatorfight.com/public/fixture_groups

Example:


  class BlahTest
    fixture_group :group1
    fixtures :foo, :bar

    ...
  end

This will look in RAILS_ROOT/test/fixtures/group1 for the fixtures. If a fixture_group isn’t specified, then the fixtures will use the normal folder.

Update 8/10/07

For the most part, I’ve given up on fixtures in my tests. Although I have it in my mind to check out fixture scenarios soon.

4 Responses to “Fixture Groups”

  1. Dustin Tinney Says:
    May 20th, 2007 at 06:56 PM

    Why didn’t you use this fixture scenarios?

  2. Zach Moazeni Says:
    May 20th, 2007 at 10:22 PM

    I didn’t come across that plugin. Looks interesting.

    I’ve actually started going to down another route, using factory type methods for most models, and relying less on fixtures.

    While fixtures are a neat concept, going fixture-happy can lead to some mean complexities with tests.

    I’m planning on posting my experience with it soon. One thing I’ve liked a lot about using factory-methods is that it’s easy to create Test DSLs that are more readable and there seems to be less setup to test corner cases.

  3. Dustin Tinney Says:
    May 21st, 2007 at 12:10 PM

    Are you talking about using something like Model.new in your tests?

    There’s a nice BDD example where you use a hash: required_attributes = {:first_name => “homer”, :last_name => “simpson”}

    And when you test edge cases use can use something like: 
    it "should require a first name" 
  model = Model.new(require_attributes.except(:first_name)
  model.see_errors_on(:first_name)
end
  4. Zach Moazeni Says:
    May 21st, 2007 at 12:32 PM

    Yep. Along the same premises. Model Unit tests haven’t been as difficult as Functional and Integration tests when the data model relationships become more complicated.

    I tend to prefer a lot of very small tests (less than 10 lines if I can help it) rather than a few very lengthy tests, and recently I’ve been going down the route of abstracting model creations, assertions, and mock expectations into DSL-like methods1

    I noticed when I relied on Fixtures more then my fixture.yml files started becoming large and unwieldy, which to me is just displacing the complexity. So the time saved on Grok’ing a test was spent on Grok’ing the fixture relationships.

    I could make the argument that perhaps my tests were “covering too much ground”, but working on Eventable it seems to be a recurring theme.

    1 – I use this term loosely, so take that with a grain of salt.

Leave a Reply