This is normal. The tests will essentially drop your test database and recreate it each time they're run, in order to ensure that they're working off the most current incarnation of your app.
If for some reason they're unable to do that, it says to me something is broken with your project or your database. What is the message you get when they fail?
Ben
The message I keep getting is that one of my tables already exists. It's the first one in my schema. I noticed that some of my tests have trouble between runs when it goes to drop certain tables, and it says there's data or foreign key problems. I fgured that was the order of the fixtures, but I don't know. How does Rails know the order to drop things in so you don't get foreign key constraint issues?
Well, I'm not entirely sure this is correct, but I *believe* that it works by deleting all the tables, then cloning the development database. Yeah, digging through the rake tasks confirms this; the test task (through a few steps of prereqs) calles db:test:purge.
How can I debug this? Is there a rake tasks that lets me drop my database? Is it user permissions? I'm logging in as root.
db:test:purge will empty your test database.
Don't log in as root 
Set up new users for your databases.
What database engine are you using? Is your test database different from your production/development databases?
Ben
It doesn't get the order right, basically. You will need to specify your fixtures in an order that will allow them to be dropped without any problems.
DHH has said not to use database constraints [1], and as such we continue to run into problems like these. I've found your best bet is not to use a database at all when testing, and to use mocks instead [2].
Pat
[1] http://www.loudthinking.com/arc/000516.html [2] Just a moment...