What's the status on flexible fixtures?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

What's the status on flexible fixtures?

Duane Johnson
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
[hidden email]
http://lists.rubyonrails.org/mailman/listinfo/rails-core
Reply | Threaded
Open this post in threaded view
|

Re: What's the status on flexible fixtures?

James Adam
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 <[hidden email]> 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
> [hidden email]
> http://lists.rubyonrails.org/mailman/listinfo/rails-core
>
_______________________________________________
Rails-core mailing list
[hidden email]
http://lists.rubyonrails.org/mailman/listinfo/rails-core
Reply | Threaded
Open this post in threaded view
|

Re: What's the status on flexible fixtures?

Tobias Lütke
In reply to this post by Duane Johnson
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 <[hidden email]> 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
> [hidden email]
> 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
[hidden email]
http://lists.rubyonrails.org/mailman/listinfo/rails-core
Reply | Threaded
Open this post in threaded view
|

Re: What's the status on flexible fixtures?

James Adam
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 <[hidden email]> 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 <[hidden email]> 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
> > [hidden email]
> > 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
> [hidden email]
> http://lists.rubyonrails.org/mailman/listinfo/rails-core
>
_______________________________________________
Rails-core mailing list
[hidden email]
http://lists.rubyonrails.org/mailman/listinfo/rails-core
Reply | Threaded
Open this post in threaded view
|

Re: What's the status on flexible fixtures?

Duane Johnson
In reply to this post by Tobias Lütke

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
[hidden email]
http://lists.rubyonrails.org/mailman/listinfo/rails-core