opensoul.org - Life without fixtures Comments

Comment on 'Life without fixtures' by But well

2008-12-12T14:27:58Z

But fixtures are loaded in a database… I don’t get your point

Comment on 'Life without fixtures' by Derek

2008-12-11T21:43:39Z

I find that there are cases where the correctness of your code relies on correct functioning of your finders. Since finders translate to SQL, and you can’t test SQL without a database backend, I find that a fixture-less approach leads to some ugly hacking and empty tests, especially when shooting for full coverage.

As an example, I have the following code in a work application:

def self.for(link)
  Score.find(:all,:conditions => {:user_id => link.user.id}, :order => 'ABS(score) desc')
end

Without fixtures the only thing I can do there is stub out “find” on Score to return an array of mock Score objects, then check that the value I get back is the value I told it to return. Sure, the line is marked as covered, but it didn’t actually test a damn thing. Aside from manually testing the calling code through the web interface, I just have to take it on faith that the finder is correctly written.

With a small set of fixtures for the Score model, on the other hand, I can easily create a mock for “link”, pass it in, and check that the fixtures I get back really are the ones I expect, in the order I expect. In this way, I ensure that the parameters I send to “find” actually work. There is literally no way to do this without a database backend for your tests.

Actually, there is one way, and that’s to rewrite the code like this:

Score.find(:all).select{|sc| sc.user_id == link.user.id}.sort{|a,b| b.score.abs <=> a.score.abs}

And in so doing, I’ve offloaded trivial database work into Ruby code. But hey, at least now I can test my code without fixtures!!

Comment on 'Life without fixtures' by Well

2008-11-05T09:50:58Z

I use fixtures for two things: 1) for automated tests of course 2) and to populate my development database

Maybe I’m wrong for 2) but it helps me have an application with correct and human readable values. I can also recreate a state of the apps easily.

Can you do the same without fixtures?

Comment on 'Life without fixtures' by nofxx

2008-10-04T11:21:10Z

Object Daddy += 1

Looks simpler, and more elegant. Object.generate!

@Andrew: The test stuff stays on /spec/exemplars/mode_name_exemplar.rb. So it`s not loaded at runtime. And the methods you end up doing are class methods like: next_valid_name , next_something….

Comment on 'Life without fixtures' by Andrew Vit

2008-09-09T02:39:39Z

One more vote for factory_girl. (Though to be honest I haven’t given the others a fair shake). I don’t really see your point of convention over configuration with factory girl… Aren’t fixture files configuration too? I have one factory.rb file which defines all of my model defaults, with some handy things like sequences for unique emails or usernames, etc… I configure it once, then I can use them anywhere in my tests, relationships and all, and overriding the default objects in individual tests as needed. I haven’t tried working stubs into the mix, but I think where I want to stub, I want to do so explicitly… though a helper method to do so would be nice.

@David: I’m not sure I like the object_daddy idea of a generate method mixed into my models. It seems like something that might interfere with a method name…

Comment on 'Life without fixtures' by Scott Taylor

2008-09-06T03:38:07Z

“The factory method also seems to go against convention-over-configuration. Instead of having a default “configuration” when your tests run, you have to configure each test. Call me lazy, but that just seems like too much work.”

Actually, one of the reasons I included String.random in FixtureReplacement was for “convention over configuration.” Each test case should express a unique situation – everything else which is irrelevant to your test case should go into before(:each) or elsewhere (FR puts all of it in one file, example_data.rb since the data is so generic).

David – I’d be interested if you used all three and if so, why you prefer ObjectDaddy over the rest. Honestly, I find that putting default values right in the model to be really gross. Thoughts?

Comment on 'Life without fixtures' by David Chelimsky

2008-08-24T17:23:58Z

I’ve been using object_daddy with some success. It adds generate and generate! methods to your model classes so you can do this:

animal = Animal.generate!

It gives you a centralized location to define valid attributes, which can, of course, be overridden by passing a Hash to the generate! method – which you can use to keep relevant data in sight in your code examples:

user = User.generate(:email => 'poorly formatted email address'
user.should have(1).error_on(:email)

Comment on 'Life without fixtures' by Paul Barry

2008-08-21T21:19:55Z

I’ve been using fixture replacement for a little while now and I think it is great. It keeps the data that is relevent to the test right there with the test, making it’s intentions clear. Factory Girl has been getting a lot of hype, but after looking at it briefly, fixture replacements seems cleaner, clearer to me. Has anyone tried both fixture replacements and factory girl and found factory girl to be better?

Comment on 'Life without fixtures' by Raj

2008-08-21T13:49:25Z

Factory girl is really really nice. Give it a try.

Comment on 'Life without fixtures' by Brandon

2008-08-21T13:36:38Z

You probably have heard of Shoulda and factory_girl from ThoughtBot. I would recommend giving them a look, as I have found them easy to work with for the factory pattern.

Comment on 'Life without fixtures' by Zach Dennis

2008-08-21T03:35:09Z

This is probably going to be ginormously long. I apologize in advance. =)

It’s been so long since I’ve used fixtures! I can’t say that I’ve missed them or any of their features. I’m sure that when they are used properly along side stubs and mocks they are much less of a pain, but I apparently wasn’t smart enough (perhaps now I am) to avoid fixture nightmares.

For the past several months I’ve been using the factory pattern with success. There have been some things I’ve found along the way similar to what you’ve mentioned: needing to have methods which build “new” objects and having methods which create “valid” objects. Recently I’ve even split out the valid attributes into their own module, ValidAttributes. My factory uses them to construct objects. ie:

module ValidAttributes
  def valid_day_attributes
    { :date => Date.today }
  end
end

module Generate
  def self.new_day(attrs={})
    Day.new valid_day_attributes.merge(attrs)
  end

  def self.day(attrs={})
    day = new_day(attrs)
    day.save!
    day
  end
end

The thing I like most about using a factory is that it allows the examples to be very explicit what is needed (or not needed) for a particular behavior. I don’t like having to scan through multiple files to understand an example. I just want to read the example to see all the pertinent information.

Regardless, I need to know what I want to get out of my factory or fixtures or anything else that tries to fill the gap. I need to be able to build/create valid objects, build/create invalid objects, construct intertwined objects (relationships) and also create objects which are a fair real-world representation of a sample set of data. I also want the important pieces to be highly visible in examples, while the non-important pieces are non-visible (or at least not competing with the important stuff for visibility).

With everything though I realize mileage can vary. My experience with factories have been good so far. My experience with fixtures were not so good.