My unit tests are failing to run. Every time I run them it fails before
getting to the actual tests because it keeps trying to update the
database schema (db:schema:load). My tests were running just fine, then
I created and new migration, updated my development database, rake
db:test:clone_structure, and then rake test:units. Why is rake trying
to update my database for me? How do I make it stop or realize that my
test database it up to date? I’ve checked the schema_version table, and
it says the latest version.
Charlie
On Wed, Sep 06, 2006, Charlie H. wrote:
My unit tests are failing to run. Every time I run them it fails before
getting to the actual tests because it keeps trying to update the
database schema (db:schema:load). My tests were running just fine, then
I created and new migration, updated my development database, rake
db:test:clone_structure, and then rake test:units. Why is rake trying
to update my database for me? How do I make it stop or realize that my
test database it up to date? I’ve checked the schema_version table, and
it says the latest version.
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?
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.
Charlie
Ben B. wrote:
On Wed, Sep 06, 2006, Charlie H. wrote:
My unit tests are failing to run. Every time I run them it fails before
getting to the actual tests because it keeps trying to update the
database schema (db:schema:load). My tests were running just fine, then
I created and new migration, updated my development database, rake
db:test:clone_structure, and then rake test:units. Why is rake trying
to update my database for me? How do I make it stop or realize that my
test database it up to date? I’ve checked the schema_version table, and
it says the latest version.
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
I’m using MYSQL 5. I know I shouldn’t use root, but for development and
testing I don’t see the harm. Once in production I’ll use different
users.
If it’s deleting tables how does it get the order right for deleting
tables without violating foreign key constraints?
Ben B. wrote:
On Wed, Sep 06, 2006, Charlie H. wrote:
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
On Wed, Sep 06, 2006, Charlie H. wrote:
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
What database engine are you using? Is your test database different
from your production/development databases?
Sorry forgot your last question. Yes I have three seperate database for
development, testing, and production.
Charlie
On 9/6/06, Charlie H. [email protected] wrote:
works by deleting all the tables, then cloning the development database.
What database engine are you using? Is your test database different
If it’s deleting tables how does it get the order right for deleting
tables without violating foreign key constraints?
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] http://glu.ttono.us/articles/2006/09/02/mocking-models
Thanks. After I did a rake db:test:purge is corrected itself and was
happy again. I guess whenever I do a db:test:clone_structure that
causes the unit test framework to be unhappy.
I’m afraid I don’t buy DHH’s opinion on constraints. I too advocate for
application database architecture and laughed at the 90210 joked he said
because he’s right it’s the old way of thinking about business
integration. But, I’m afraid constraints are an imporant thing and
rails should learn to work with them. The biggest argument I have for
adding constraints to your data is so that you’ll know when something is
violating your data. Does your program work because you added
constraints? No that’s not the point of them. At least you’ll know
when you aren’t working properly and the exception stack trace will
point you to the offender fairly quickly.
For now I’ll just keep adding my fixtures in the right order. Actually
I’m getting pretty sick of fixtures as a means to communicate test data.
There has to be a better way.
Thanks
Charlie
Pat M. wrote:
On 9/6/06, Charlie H. [email protected] wrote:
works by deleting all the tables, then cloning the development database.
What database engine are you using? Is your test database different
If it’s deleting tables how does it get the order right for deleting
tables without violating foreign key constraints?
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] http://glu.ttono.us/articles/2006/09/02/mocking-models