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