This has been on my todo list for quite some time, so I''m pleased to announce the availability of a flexible fixture module. In short, it solves some difficulties that arise from the hard-coded assumptions of the current fixture architecture: in some cases it is not good to assume that there is only one set of fixture data per table for the entire application. WIth this module, you can create several fixture files for the same database table but with different purposes, thus separating concerns and reducing cross dependencies among test suites and fixture data. Sample code: class MyUserTestSuite < Test::Unit::TestCase fixture :users, :file_name => "signed_up_users" ... end Please see the following wiki entry for a more complete explanation and the fixtures.rb module itself: http://wiki.rubyonrails.com/rails/show/FlexibleFixtures This may make it in to the rails core, but I thought it might be useful to others now since many of the core contributors are busy at the moment (i.e. OSCON :) If you would like to patch your rails code instead, you can get the diff here: http://dev.rubyonrails.com/ticket/1911 Duane Johnson (canadaduane)
> This has been on my todo list for quite some time, so I''m pleased to > announce the availability of a flexible fixture module. In short, it > solves some difficulties that arise from the hard-coded assumptions > of the current fixture architecture: in some cases it is not good to > assume that there is only one set of fixture data per table for the > entire application. > > WIth this module, you can create several fixture files for the same > database table but with different purposes, thus separating concerns > and reducing cross dependencies among test suites and fixture data.Fantastic! I needed this for my weekend project but didn''t know it :) There''s another option I''ll be needing for this too: the ability to run fixtures against another database connection. I have a central model used for authentication. Assuming this gets accepted into Rails, I''ll make this addition once the need comes up. # Uses the User model''s connection properties fixture :users, :file_name => "signed_up_users", :class_name => ''User'' Actually looking at this, your example seems a little backwards. The fixture files always map to file names, not models necessarily. This is closer to what I was thinking. # uses Group.table_name and Group.connection fixture :groups # uses User.table_name and fixture :signed_up_users, :class_name => ''User'' User.connection # used for HABTM, no model found so uses groups_users table and AR::Base.connection fixture :groups_users Just some thoughts... -- rick http://techno-weenie.net
On Aug 8, 2005, at 10:54 AM, Rick Olson wrote:> # Uses the User model''s connection properties > fixture :users, :file_name => "signed_up_users", :class_name => ''User'' > > Actually looking at this, your example seems a little backwards. The > fixture files always map to file names, not models necessarily. This > is closer to what I was thinking. > > # uses Group.table_name and Group.connection > fixture :groups > > # uses User.table_name and > fixture :signed_up_users, :class_name => ''User'' User.connection > > # used for HABTM, no model found so uses groups_users table and > AR::Base.connection > fixture :groups_users >Well, well. I hadn''t thought of that. This shouldn''t be too difficult a change to make. So what you''re saying is that in all cases it''s safe to assume that the fixture''s file name is the name of the fixture group used in the test unit (the instance variable, e.g. @signed_up_users)? I was thinking for some reason that it''s better to make it flexible... but since your assumption is almost always true, I''ll reverse the declaration so that the first parameter (e.g. "fixture :signed_up_users") corresponds with the fixture''s file name. I''ll add a :group_name optional parameter in the off chance that the developer would like to re-name the local instance variable to something other than the fixture''s file name. And I''ll see if I can use the connection and table name from the model, as you suggest.> Just some thoughts... >Thanks Rick! Duane Johnson (canadaduane)
The suggestions that Rick made are now implemented--however, I don''t have time right now to add the necessary modifications to dynamically use the model-specific connections to the database. Rick, do you have time to look at that? The newest patch is here: http://dev.rubyonrails.com/attachment/ticket/1911/ more_flexible_fixture_architecture-2.patch Duane Johnson (canadaduane)
On 8/8/05, Duane Johnson <duane.johnson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> The suggestions that Rick made are now implemented--however, I don''t > have time right now to add the necessary modifications to dynamically > use the model-specific connections to the database. > > Rick, do you have time to look at that? The newest patch is here: > http://dev.rubyonrails.com/attachment/ticket/1911/ > more_flexible_fixture_architecture-2.patchI''ll take a look at it later today when I get some time... I didn''t think the model-specific connections would be easy to implement. I''ll get to that later when I actually need it. I really could''ve used this for the Instiki-AR transition this weekend. It''s unit tests had several methods to load different data that I ended up having to shove into one fixture file. This threw off a lot of the counts that weren''t expecting these extra pages. I''ll try this in the Instiki RSS tests that load 30 sample pages, however. Thinking about the Instiki tests, BTW, it would be cool if you could specify fixtures for certain test methods only using :only or :except options (unless transaction fixtures are used). I''ll try my hand at that if it''ll be useful in the Instiki RSS tests. -- rick http://techno-weenie.net