[Rails] Design flaw with Fixtures?

Joseph Moore
2006-01-12T05:20:20Z

Here''s my own take:
http://www.josephmoore.net/2005/12/unit-testing-leave-no-trace-vs-schmutz.html

On our Rails projects, we decided to take the opposite extreme, despite my
propensity for Leave No Trace vs. Schmutz: we added code to test_helper.rb
that loads *all fixtures* during setup.  By doing this, we guarantee that
all data is nuked before tests run, and all tests have the same exact data
with which to play.  And no, we don''t have a ton of fixture data.

At first I was against this, but I''ve come the to conclusion that the
"promise" we make to our tests is not that they will start with a
clean
slate, but that they will start from a known starting point; this is not the
necessarily case with Rails'' current "only delete referenced
fixtures"
model.  By loading all fixtures, our tests behaved the same regardless of
"starting-empty" vs. "delete-all-data then load-all-data."

-- Joe



On 1/7/06, Dudley Flanders <dudley@misnomer.us>
wrote:
>
>
> On Jan 7, 2006, at 3:46 AM, Derek Haynes wrote:
>
> > On a related note, something I''ve wondered about when
defining foreign
> > key relationships in the database: should this even be done when we
> > can ensure relationships using validation methods? It seems like this
> > is a violation of DRY unless another application needs to directly
> > interact with the database.
>
> Check out http://www.loudthinking.com/arc/000516.html for DHH''s
take on
> this. If you''re only hitting the database from your Rails app,
there''s
> really no reason to bother with foreign key constraints.
>
> -dudley
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
-------------- next part --------------
An HTML attachment was scrubbed...