I''ve been bugged recently by the way table names are resolved for test fixtures. A side-effect of the current method is that you have to name all of your fixture accessors after the table, rather than after the class name. This means that things get a little less obvious for people using set_table_name, or Single Table Inheritance. For example, if I have AddressItem < Item and Item < ActiveRecord::Base, I have to use "fixtures :items" instead of "fixtures :address_items", and merge all my STI fixtures into one file. I noticed this patch today: http://dev.rubyonrails.org/ticket/4095 ..and was inspired to do something about it. The attached patch works nicely with my unit tests, and doesn''t seem to break anything.. but I''d appreciate if people using various platforms could give it a shot. Also, does this approach look like something appropriate for the core? I''ve seen a number of people ask about this on the Rails list, and go unanswered. If so, I''ll make a ticket for it. Thanks, --Wilson. _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
On 3/23/06, Wilson Bilkovich <wilsonb@gmail.com> wrote:> > I''ve been bugged recently by the way table names are resolved for test > fixtures. > A side-effect of the current method is that you have to name all of > your fixture accessors after the table, rather than after the class > name. > This means that things get a little less obvious for people using > set_table_name, or Single Table Inheritance. > > For example, if I have AddressItem < Item and Item < > ActiveRecord::Base, I have to use "fixtures :items" instead of > "fixtures :address_items", and merge all my STI fixtures into one > file. > I noticed this patch today: > http://dev.rubyonrails.org/ticket/4095 > ..and was inspired to do something about it. > > The attached patch works nicely with my unit tests, and doesn''t seem > to break anything.. but I''d appreciate if people using various > platforms could give it a shot. > Also, does this approach look like something appropriate for the core? > I''ve seen a number of people ask about this on the Rails list, and go > unanswered. If so, I''ll make a ticket for it. > > Thanks, > --Wilson. > > > >Worked as expected here for a small test case. I don''t know how I feel about breaking them up in fixtures when the tables are all of the data combined. I guess I can kinda see both sides for keeping them in a single fixture or breaking them out into a couple. This feels natural though. -- Corey Donohoe http://www.atmos.org/ corey.donohoe@gmail.com _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
On 3/24/06, Corey Donohoe <corey.donohoe@gmail.com> wrote:> On 3/23/06, Wilson Bilkovich <wilsonb@gmail.com> wrote: > > I''ve been bugged recently by the way table names are resolved for test > fixtures. > > A side-effect of the current method is that you have to name all of > > your fixture accessors after the table, rather than after the class > > name. > > This means that things get a little less obvious for people using > > set_table_name, or Single Table Inheritance. > > > > For example, if I have AddressItem < Item and Item < > > ActiveRecord::Base, I have to use "fixtures :items" instead of > > "fixtures :address_items", and merge all my STI fixtures into one > > file. > > I noticed this patch today: > > http://dev.rubyonrails.org/ticket/4095 > > ..and was inspired to do something about it. > > > > The attached patch works nicely with my unit tests, and doesn''t seem > > to break anything.. but I''d appreciate if people using various > > platforms could give it a shot. > > Also, does this approach look like something appropriate for the core? > > I''ve seen a number of people ask about this on the Rails list, and go > > unanswered. If so, I''ll make a ticket for it. > > > > Thanks, > > --Wilson. > > > > Worked as expected here for a small test case. I don''t know how I feel > about breaking them up in fixtures when the tables are all of the data > combined. I guess I can kinda see both sides for keeping them in a single > fixture or breaking them out into a couple. This feels natural though. >Thanks for checking it out. I forgot to say this in my first message, but the basic premise is that I should be able to refer to my fixtures by the name of the model class, without caring about the name of the table. It''s easier for me to remember "fixture :some_subclass" when I''m writing tests for that particular set of behavior.