On Dec 20, 2005, at 9:35 AM, Tobias Luetke wrote:
What is the reason for making fixtures more complicated? I don't see the reason for needing more then one set of fixtures, you could just add more fixtures if you need to test new things.
There are several reasons for needing this patch. One use case, given recently on the mailing list, is a situation where non-standard database names and conventions make the fixture assumptions fail. From Dan Tenenbaum:
I am working with a legacy database that does not always follow the conventions for table names, primary key and foreign key column names, and join table names. This is no problem in my application code because Rails allows me to override the defaults. However it is making unit testing next to impossible because fixtures will still try and insert data into the wrong tables. Changing the database schema is not an option at this point as the database is already deployed to a production environment and has been for some time. The problem and solution are described here: http://dev.rubyonrails.org/ticket/1911
In addition to this use case, separating fixtures from each other can actually have the effect of *simplifying* rather than complicating unit tests. For example, I've written some fairly complex statistics- gathering reports for a Rails application. The interdependencies were such that it became very frustrating to add any fixtures for other unit tests after writing the test code for the reports, because doing so meant that it would skew all of the results for the reports.
I think there is value in keeping fixtures straight forward; What you want to do is to model a sensible "test" database with your fixtures. In shopify we decided to model a test database based on a store selling winter sports gear ( homage to snowdevil ). The fixtures are telling different stories on their own. For example the order table has a lot of orders during the christmas months. The fixtures have names like "bobs_birthday_present_order".
I think you're right, for most cases. The straight-forward assumptions help guide developers when writing unit tests and functional tests. However, as mentioned above, there are some legitimate cases when a little more flexibility is not only desirable but necessary.
Perhaps James can explain why this flexibility is necessary for Engines also.
Thanks, Duane Johnson (canadaduane) http://blog.inquirylabs.com/ _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
