Testing database (was Re: [jifty-devel] Tutorial questions)

[Rob Kinyon]

> > 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
stuff.

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:

development:
  adapter: mysql
  database: depot_dev
  username: rob
  password:
  socket: /tmp/mysql.sock

  # Connect on a TCP socket.  If omitted, the adapter will connect on the
  # domain socket given by socket instead.
  #host: localhost
  #port: 3306

# 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.
test:
  adapter: mysql
  database: depot_test
  username: rob
  password:
  socket: /tmp/mysql.sock

production:
  adapter: mysql
  database: depot_production
  username: depot_prod
  password: depot_prod
  socket: /tmp/mysql.sock

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
first:
  id: 1
  title: Some book
  description: It's a book, dummy
  image_url: http://somewhere.com/foo.jpg
  price: 0.99
  date_available: 2001-01-01 00:00:00
second:
  id: 2
  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.

Rob