Comments on: mocked_fixtures: reuse fixtures as mocks without the database http://duckpunching.com/mocked_fixtures-reuse-fixtures-as-mocks-without-the-database Ruby, Rails and tech. No ducks were harmed in the making of this blog. Thu, 24 Dec 2009 20:37:45 +1100 http://wordpress.org/?v=2.8.4 hourly 1 By: Adam http://duckpunching.com/mocked_fixtures-reuse-fixtures-as-mocks-without-the-database/comment-page-1#comment-65 Adam Wed, 03 Sep 2008 20:58:21 +0000 http://duckpunching.com/?p=52#comment-65 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. 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.

]]> By: Jerry Cheung http://duckpunching.com/mocked_fixtures-reuse-fixtures-as-mocks-without-the-database/comment-page-1#comment-64 Jerry Cheung Wed, 03 Sep 2008 17:21:23 +0000 http://duckpunching.com/?p=52#comment-64 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. 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.

]]>