--- Scott Willson <scott@[...].com>  wrote:

>  Yeah, that's basically the deal, though it's not
>  obvious from the  
>  RDocs. You can pre-populate the database before your
>  tests run and  
>  use transactional_fixtures. Transactional fixtures
>  are perhaps  
>  misnamed, as any database changes made by your tests
>  roll back, but  
>  the fixtures do NOT. Fixtures are still deleted,
>  inserted and  
>  committed for each test.
>  
>  I admit that I didn't like the approach either -- in
>  previous Java  
>  projects, the team introduced nasty sequence
>  problems in tests when  
>  we relied on pre-populated data. But after I fiddled
>  with the order  
>  of my fixtures to account for foreign key
>  constraints, it works fine  
>  and the transactions keep the test fast.

The approach also causes problems if you have triggers
that disallow deletes from tables. We have data that
we are required by law to only delete after 7,
sometimes 20 years. So I created a trigger to prevent
that from occuring. We ended up rewriting how the
tests work from rake to building the schema from
scratch every time. It fortunately only takes about 20
seconds.

Shawn Garbett


		
__________________________________________ 
Yahoo! DSL Â? Something to write home about. 
Just $16.99/mo. or less. 
dsl.yahoo.com 

_______________________________________________
Rails mailing list
Rails@[...].org
http://lists.rubyonrails.org/mailman/listinfo/rails