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

Alex Vandiver alexmv at bestpractical.com
Wed Jan 4 14:10:46 EST 2006


On Wed, 2006-01-04 at 13:37 -0500, Rob Kinyon wrote:
> 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.

Right.  What Jifty does right now is kinda similar.  It creates the
database, fills it with any rows you have in your Test class (more on
this later :), runs the test, and then wipes the database.  Wiping the
database after running the test was a relatively recent change, and
mostly only because I was tired of seeing old test databases lying
around.  I don't think we're particularly wedded to it.

> 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.
I would say that for one-off applications, you *can* default to SQLite.
Sure, many people will want a more robust DB backend, but that just
means we should make it easier to specify databases.  I don't think it's
wrong to have a sane default.

> 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.
Yeah, I can see that.  Stealing that might make some sense.

> 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.
Here's how we're doing this in one of our in-house Jifty apps -- this
can certainly be made better, but it's partially there.  It's like
making fixtures, but in code rather than a data file.

package MyApp::Test;
use base qw/Jifty::Test/;

sub setup {
  my $class = shift;
  $class->SUPER::setup;

  my $ADMIN = MyApp::CurrentUser->superuser;

  my $widget = MyApp::Model::Thingy->new(current_user => $ADMIN);
  $widget->create(
    foo => "bar",
    baz => "troz",
  );
  # And so on..
}

# You can also:
sub test_config {
  # Customize the config file for testing
  my $class = shift;

  my ($config) = @_;
  my $hash = $class->SUPER::test_Config($config);
  $hash->{framework}{LogConfig} = "some/log4perl.conf";
  return $hash;  
}


More information about the jifty-devel mailing list