Testing database (was Re: [jifty-devel] Tutorial questions)
rob.kinyon at gmail.com
Wed Jan 4 13:37:54 EST 2006
> > 5) Whenever I ran "make test", the weblogtest database would
> > disappear! This means I cannot run "make test" twice in a row. Why
> > does it disappear?!? This is a serious usability issue.
> Starting your testing with a dirty database is a serious probelm in my
> book. Can you explain what you're trying to do in a bit more detail?
> (Break this one out into a separate message?)
In Rails, the equivalent of "make test" does the following actions:
1) Logs into the testing database (as specified in the
conf/databases.yml, more on this later)
2) For each testcase (.t file in the Perl world), does the following:
a) Drops every table in reverse create order
b) Recreates every table
c) Reloads every table from fixtures (more on this later)
d) Runs the test
3) Reports on the final testing results
So, each testcase has a completely fresh database to work with that's
in a known state. That setup is very very very cool. Like, a lot and
The two features you're missing are as follows:
1) conf/databases.yml - you'd call it etc/databases.yml. This is
critical. Even though all the rest of the configuration can be
defaulted, your database conf cannot be. A standard Rails
databases.yml looks something like:
# Connect on a TCP socket. If omitted, the adapter will connect on the
# domain socket given by socket instead.
# Warning: The database defined as 'test' will be erased and
# re-generated from your development database when you run 'rake'.
# Do not set this db to the same as development or production.
This allows for a number of things:
1) I can change the DB engine without changing the rest of my configuration
2) I can change the DB configuration on a per-machine basis
without touching the rest of the configuration.
2) Fixtures - this is arguably the second most powerful feature of
ActiveRecord (which is Ruby's ORM). If given a YAML file named
appropriately, it will load that file into the table when asked. These
are generally used for testing, but are really nice to have when
resetting the dev database or for demos. I've also found them really
handy for actually fleshing out how you want the schema to work.
A standard Ruby fixture would look something like:
# Read about fixtures at http://ar.rubyonrails.org/classes/Fixtures.html
title: Some book
description: It's a book, dummy
date_available: 2001-01-01 00:00:00
title: Something else
The names are used when working with Rails's testing features. They
aren't actually loaded into the table. The rows -are- loaded in the
order they're seen, but that shouldn't be depended on. The indents,
obviously, are column names.
More information about the jifty-devel