duck_punching

Ruby, Rails and tech. No ducks were harmed in the making of this blog.

mocked_fixtures: reuse fixtures as mocks without the database

For a while I have sitting on this plugin called mocked_fixtures. I wrote most of it a few months ago and added a few things here and there but just hadn’t got round to releasing it.

Basically it loads your fixtures files as mock model objects with the values from the fixture stubbed out on the mock. It saves you having to stub lots of attribute methods on your mocks with values that could have just as happily come from your fixtures. After all if you are still using fixtures then they often have a fair bit of thought behind them. So why not use them again but practice some good test isolation and remove the database from the picture.

I am using it in projects, mostly in controller and view specs to save myself a ton of stubbing code to get a passable mock object to use. Of course you can alter the mock object after you have created it to further customise it, after all it is just a mock.

The problem is I don’t how useful people will find it, given this huge push towards complete fixture replacements with FactoryGirl, model_stubbing , unit-record and the like. Its not an answer to those or even one in the herd since it still relies on fixtures.

Its really for those who like fast tests, test isolation and still use fixtures. I will be interested to see if it gets used.

I am not even going to go in depth here coz the readme does just that. So if you want to have a look then go to the source.

2 comments

2 Comments so far

  1. Jerry Cheung September 4th, 2008 3:21 am

    At work we’ve been using our own factory class for testing. It’s simply a class with a class method for every complex object in our app. You use it like Factory.create_order(:currency => Factory.create_currency). FactoryGirl’s syntax looks clean, but I imagine your plugin could still be useful for applications with a lot of existing fixtures.

  2. Adam September 4th, 2008 6:58 am

    Some of the argument against fixtures is the visibility of them in your tests. If you are writing tests around a behaviour and need precise values to test it and they are off in a fixture file somewhere, it makes the spec/test less transparent and demonstrative.

    But when you scale up something like object factories where you place the factories in another file, then the same issue of transparency applies.

    That being said I realise there are many more arguments against fixtures.

    One feature that might add to the appeal of the plugin is a feature I plan to add where you can pass a block to the fixture accessor and change the fixture values or stub other methods just for those mock fixtures returned. An example:

    @company = mock_companies(:megacorp) do |r|
    r.stub!(:non_attribute_method).and_return(‘something’)
    r.existing_attribute = ‘overrided value’
    end

    This enables easier/neater local customisation for your fixture. It would also apply to fixtures returned if you were returning multiple fixtures.

    Its not in the plugin yet but I plan to add it.

Leave a reply

Mexico