--- Kirrily Robert <[EMAIL PROTECTED]> wrote:
> 2. Assume a directory t/data (or t/fixtures if you will -- I just
> call
> it data in my own tests).
> 3. Create a file t/data/foo.yml (or whatever data format) containing
> the
> data needed by the tests in foo.t
> 4. At the beginning of foo.t, load data/foo.yml into whatever data
> structure (memory, SQLite, real database, etc)
> 5. Run tests against foo.t
> 6. When foo.t exits, tear down the data created in step 4.
>
> Yes? In other words "fixtures" is just a jargony name for t/data/,
> right?
Pretty much, for the common sense that the term is often used (though
as noted people tend to have different definitions.
> And, is the above setup/teardown stuff right, or would you do it
> before
> each individual test? That would seem to be nearly nonsensical, but
> then, I've seen stupider ideas.
Well, many languages consider a 'test' to be a set of asserts. So with
Test::Class, the following would be considered *one* test by a Java
programmer but *four* tests by a Perl programmer:
sub customer_name : Tests(4) {
my $test = shift;
my $class = $test->testing_class;
ok my $cust = $class->new('bob'),
'Creating a new customer should work';
isa_ok $cust, $class, '... and the object it returns';
can_ok $cust, 'name';
is $cust->name, 'bob',
'... and it should return the correct name';
}
That's one of the reasons for conceptual mismatches for different
programmers.
> My earlier comment about Test::Builder-based test modules was that
> some
> of the fixtures stuff I've seen used repeated code chunks to go over
> the
> contents of foo.yml, for instance doing validation runs against each
> record, and it looked to me as if the Perlish way to do that is to
> write
> a test module that provides record_is_valid() and related stuff. As
> I
> understand it now, this isn't actually part of "fixtures"
> conceptually,
> it's just something that one might tend to see near fixtures.
Well, here's one way I do test fixtures with regular .t programs:
use Test::More tests => 5;
use Our::Test::Database;
my ( $class, $dabase );
BEGIN {
$database = Our::Test::Database->new;
$class = 'Customer';
use_ok $class or die;
}
ok my $cust = $class->new('bob'),
'Creating a new customer should work';
isa_ok $cust, $class, '... and the object it returns';
can_ok $cust, 'name';
is $cust->name, 'bob',
'... and it should return the correct name';
'Our::Test::Database' starts with something like (can't recall the
exact syntax) and use Template::Toolkit:
DROP DATABASE [% test_database %] if exists;
CREATE DATABASE [% test_database %];
USE [% test_datbase %]
# table definitions
Note that much of the above is simply handled for me with Test::Class,
but I tend to use Test::Class for OO tests and .t files for procedural
code. It seems a better conceptual match.
Later, the 'Our::Test::Database' has a DESTROY method which drops the
database. At the beginning and end of every .t file, the database is
created from scratch and destroyed.
You can also create a test helper module which can populate the
database with sample data (or at least static data which should always
exist), though this means that the programmer looking at a test doesn't
immediately see what data's in the database.
Cheers,
Ovid
--
Buy the book -- http://www.oreilly.com/catalog/perlhks/
Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
