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.

Scott


On Dec 4, 2005, at 2:47 PM, Forrest L Norvell wrote:

>  Hi! I'm a newbie wrapping my head around the Rails way of designing  
>  apps
>  at the database layer, and I've hit a minor conceptual logjam and was
>  hoping some of you might be able to help work me through it.
> 
>  ...

>  My problem is that using fixtures and transactional unit tests, I have
>  to incorporate all the fixtures for the classes in the foreign key
>  restrictions to ensure that fixtures get set up and torn down  
>  correctly.
>  I.e. unless I have a line that says "fixtures :artists, :albums,
>  :tracks" in test/unit/(album|artist|track)_test.rb, the test database
>  isn't left in a sane state across unit tests and unit tests start
>  failing due to integrity constraint errors when the fixture code tries
>  to empty out the table during the fixture setup invoked by the  
>  fixtures
>  method.
> 
>  It was a bit of an effort to figure all that out, and my solution  
>  feels
>  hacky. Why should I have to set up fixtures for tracks and albums when
>  I'm only testing artists, who sit at the top of this hierarchy? And
>  how's that going to play when I add in many-to-many relationships
>  between groups (artists) and their members? And glom genres onto this?
>  It seems like this is going to make my test cases increasingly complex
>  and unwieldy.
> 
>  Is it already time for me to abandon using "fixtures" in my test cases
>  and start doing explicit fixture setup and teardown? Or is there a
>  simple way I can modify the framework, e.g. to automatically clear out
>  all of the fixtures used by an individual test case? I can't  
>  imagine I'm
>  the only person who's run into this.

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