# Test Fixture Alternatives **URL:** \ **Category:** Rails\ **Created:** [January 2, 2007, 7:17pm UTC](https://www.ruby-forum.com/t/test-fixture-alternatives/80979 "2007-01-02T19:17:17Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![jonlog](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/db5fbb/32.png) [@jonlog](https://www.ruby-forum.com/u/jonlog)\ **Post date:** [January 2, 2007, 7:17pm UTC](https://www.ruby-forum.com/t/test-fixture-alternatives/80979/1 "2007-01-02T19:17:17Z")
## Didn’t get any responses to my previous posting of this, so I figured I’d try once more now that the holidays are over and people are hopefully getting back into the swing. We’ve run into an issue on a project with one fixture that’s failing because it’s getting loaded before another fixture that it’s dependent on. Only happens on one test. Many other tests that use both fixtures work fine. After a little searching on the net, I find that we’re not the first to run into issues with the order in which fixtures get loaded. The best solution I’ve found mentioned is pretty much total abandonment of fixtures and instead using helper methods that create appropriate data. The advantages seem to be a) solving the load order problem we’re having and b) tests run faster. Nowhere that I see this talked about do I see people discuss any disadvantages, so… my questions are? Are there any disadvantages to using helper methods instead of fixtures? What are they? If helper methods really are more advantageous than fixtures, why isn’t it standard procedure to create the helper methods from the beginning? Every bit of documentation I’ve read in regards to getting started in testing says to create fixtures, with no hint of other, potentially more appropriate, means of getting test data into the database. Are there any other solutions to our problem that I haven’t discovered? ---
**Author:** ![jonlog](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/db5fbb/32.png) [@jonlog](https://www.ruby-forum.com/u/jonlog)\ **Post date:** [January 2, 2007, 11:12pm UTC](https://www.ruby-forum.com/t/test-fixture-alternatives/80979/2 "2007-01-02T23:12:25Z")
What’s the specific problem you’re having. I’m not sure this will help, but some people are moving to mocks instead of fixtures when database functionality is not what’s under test. The fixture names are kept in a table\_name=\>fixture hash so order is not guaranteed. I know the Engines people (I believe canadaduane) wrote some extensions to help with fixture flexibility, but as I recall it was to allow you to have more than one possible fixture for a given model. Their code might help you find a way to tweak the order. –steve Jon G. wrote: > work fine. After a little searching on the net, I find that we’re not > > > – View this message in context: [http://www.nabble.com/-Rails--Test-Fixture-Alternatives-tf2909204.html#a8131685](http://www.nabble.com/-Rails--Test-Fixture-Alternatives-tf2909204.html#a8131685) Sent from the RubyOnRails Users mailing list archive at [Nabble.com](http://Nabble.com). ---
**Author:** ![jonlog](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/db5fbb/32.png) [@jonlog](https://www.ruby-forum.com/u/jonlog)\ **Post date:** [January 3, 2007, 12:28am UTC](https://www.ruby-forum.com/t/test-fixture-alternatives/80979/3 "2007-01-03T00:28:33Z")
s.ross wrote: > What’s the specific problem you’re having. > A simplified example would be something like rather than hard coding the > id’s for a has\_many-\> belongs\_to relationship between two models, the > second looks up who it belongs to via code… eg. thing: owner\_id: \<%= Owner.find\_by\_name(‘Joe’).id %\> which is more flexible, and a lot clearer when looking at the yaml file than… owner\_id: 23 and works fine as long as the owners.yml file gets loaded before the things.yml. But when owners.yml hasn’t been loaded yet, things.yml obviously croaks. With all the tests we’ve got that load fixtures like this, it’s kind of amazing we just now ran into this issue. We’ve been assuming all this time that the fixtures were loading in the order we presented them with no reason to think otherwise, since it all worked great. ---
**Author:** ![jonlog](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/db5fbb/32.png) [@jonlog](https://www.ruby-forum.com/u/jonlog)\ **Post date:** [January 3, 2007, 12:46am UTC](https://www.ruby-forum.com/t/test-fixture-alternatives/80979/4 "2007-01-03T00:46:37Z")
Jon G. wrote: > We’ve run into an issue on a project with one fixture that’s failing > because it’s getting loaded before another fixture that it’s dependent > on. Only happens on one test. Many other tests that use both fixtures > work fine. At a guess, go to the top of the /test/fixture/module.yml file that needs the other fixtures, and add this line: \<% load\_fixture(‘some\_other\_model.yml’) %\> You gotta write the load\_fixture method; it will have something to do with the Fixtures.create\_fixtures() method. – Phlip [http://c2.com/cgi/wiki?ZeekLand](http://c2.com/cgi/wiki?ZeekLand) ← NOT a blog!! ---
**Author:** ![jonlog](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/db5fbb/32.png) [@jonlog](https://www.ruby-forum.com/u/jonlog)\ **Post date:** [January 3, 2007, 2:38am UTC](https://www.ruby-forum.com/t/test-fixture-alternatives/80979/5 "2007-01-03T02:38:52Z")
Jon G. wrote: > loaded. The best solution I’ve found mentioned is pretty much total > it standard procedure to create the helper methods from the beginning? > Every bit of documentation I’ve read in regards to getting started in > testing says to create fixtures, with no hint of other, potentially more > appropriate, means of getting test data into the database. > > Are there any other solutions to our problem that I haven’t discovered? I’ve been using the approach you describe for building fixtures on the fly. Basically what I do is write a helper method that I put in the test/mock file for each model. This method (called ‘new\_fixture’) will generate a new fixture that has certain properties. It generally can return an empty object, an invalid object, a valid object, a deleted object, and a non-existent object. The valid objects are constructed so that they pass the AR validation tests, and the invalid ones will fail them. The non-existent object returns a blank object with its :id set to a value that does not exist in the test database. A deleted object is one that has it’s ‘deleted\_at’ attribute set (as per acts\_as\_paranoid). This method gives you the option to save the object in the test db if needed. This may not be faster than standard fixtures, but you can add a few assertions to make sure the mock object is returning the correct types of object (i.e., you can assert that they are valid). You can now refactor your model knowing that you won’t have to generate new fixtures or deal with corrupt ones because you changed how the model works. All you might have to do is update the ‘new\_fixture’ method. \_Kevin ---
**Author:** ![jonlog](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/db5fbb/32.png) [@jonlog](https://www.ruby-forum.com/u/jonlog)\ **Post date:** [January 3, 2007, 10:56pm UTC](https://www.ruby-forum.com/t/test-fixture-alternatives/80979/6 "2007-01-03T22:56:38Z")
s.ross wrote: > some people are moving to mocks instead of fixtures when database > functionality is not what’s under test. I’m one of them. Unit tests should rarely need fixtures, and functional tests should not rely on model implementation. The one challenge with using mocks for functional testing is it is much easier to do if you have split controller and view tests. Right now I only know of RSpec and Test::Rails which will do that. I wrote a short example on my blog about the benefits of using mocks: [http://www.dcmanges.com/blog/16](http://www.dcmanges.com/blog/16) Dan M. ---
**Author:** ![jonlog](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/db5fbb/32.png) [@jonlog](https://www.ruby-forum.com/u/jonlog)\ **Post date:** [January 3, 2007, 1:04am UTC](https://www.ruby-forum.com/t/test-fixture-alternatives/80979/7 "2007-01-03T01:04:39Z")
Phlip wrote: > At a guess, go to the top of the /test/fixture/module.yml file that > needs the other fixtures, and add this line: > > \<% load\_fixture(‘some\_other\_model.yml’) %\> > > You gotta write the load\_fixture method; it will have something to do > with the > Fixtures.create\_fixtures() method. Hmmm, creative idea. I definitely hadn’t thought of doing anything like that.