Hi, I talked with bitsweat about flexible fixtures at RubyConf but haven''t heard much since. The patch accompanying ticket #1911 hasn''t been applied, but it looks like #2292 has. There''s been some wishing for this functionality on the list lately, and just wondered what the state of things are. Duane Johnson (canadaduane)
I can second this interest - I''ve adapted Duanes patch for our projects and it''s a sound piece of code, I can''t see any reason why it shouldn''t be a part of Rails proper. On 12/18/05, Duane Johnson <duane.johnson@gmail.com> wrote:> Hi, > > I talked with bitsweat about flexible fixtures at RubyConf but > haven''t heard much since. The patch accompanying ticket #1911 hasn''t > been applied, but it looks like #2292 has. There''s been some wishing > for this functionality on the list lately, and just wondered what the > state of things are. > > Duane Johnson > (canadaduane) > _______________________________________________ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core >
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. 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". A lot of bugs are found because our test data is organic and is virtually a fully functioning shopify installation. We find many seemingly unrelated breakage because all the tests work on the same data. I think that this is one of the strengths of the current fixture system. On 12/18/05, Duane Johnson <duane.johnson@gmail.com> wrote:> Hi, > > I talked with bitsweat about flexible fixtures at RubyConf but > haven''t heard much since. The patch accompanying ticket #1911 hasn''t > been applied, but it looks like #2292 has. There''s been some wishing > for this functionality on the list lately, and just wondered what the > state of things are. > > Duane Johnson > (canadaduane) > _______________________________________________ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core >-- Tobi http://jadedpixel.com - modern e-commerce software http://typo.leetsoft.com - Open source weblog engine http://blog.leetsoft.com - Technical weblog
I''m not sure this is what Duane was suggesting - all his patch gives is some optional control over which table and which class is used to load a particular fixtures file... - james On 12/20/05, Tobias Luetke <tobias.luetke@gmail.com> 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. > > 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". > > A lot of bugs are found because our test data is organic and is > virtually a fully functioning shopify installation. We find many > seemingly unrelated breakage because all the tests work on the same > data. I think that this is one of the strengths of the current fixture > system. > > > > On 12/18/05, Duane Johnson <duane.johnson@gmail.com> wrote: > > Hi, > > > > I talked with bitsweat about flexible fixtures at RubyConf but > > haven''t heard much since. The patch accompanying ticket #1911 hasn''t > > been applied, but it looks like #2292 has. There''s been some wishing > > for this functionality on the list lately, and just wondered what the > > state of things are. > > > > Duane Johnson > > (canadaduane) > > _______________________________________________ > > Rails-core mailing list > > Rails-core@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails-core > > > > > -- > Tobi > http://jadedpixel.com - modern e-commerce software > http://typo.leetsoft.com - Open source weblog engine > http://blog.leetsoft.com - Technical weblog > _______________________________________________ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core >
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/1911In 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/