Hiya,
On 13 Feb 2007, at 22:46, Kirrily Robert wrote:
Thanks all, especially Ovid who came closest to answering the actual
question, i.e. can someone explain it to me *in a perlish way*.
Ovid's
example used Test::Class's setup/teardown;
You saying that T::C isn't Perlish? Wanna make something of it ;-)
would anyone else be able to
provide confirm that I'm making sense in the following
Test::Harness/Test::More style example:
1. Assume a test file t/foo.t
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?
Roughly yes.
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.
[snip]
With an xUnit style you would do it before every test method, and
each test method might have one or more assertions (which correspond
roughly to what we call "tests" in the Perl world - something that
pushes out an ok/not ok).
So, with a T::M style you might see something like;
sub make_fixture {
my $usd5 = Money->new( usd => 5 );
my $usd2 = Money->new( usd => 2 );
my $fr5 => Money->new( fr => 5 );
my $purse = Purse->new( usd => 2, fr => 1 );
}
{ diag 'can we add money to a purse';
my ($usd5, $usd2, $fr5, $purse) = make_fixture();
$purse->add( $usd5, $fr5 );
is $purse->amount( 'usd' ), 7, '$5 + purse with $2 = $7';
is $purse->amount( 'fr' ), 6, '5fr + purse with 1fr = 6fr';
}
{ diag 'can we take money out of a purse'
my ($usd5, $usd2, $fr5, $purse) = make_fixture();
my $m = $purse->remove( usd => 1 );
is_deeply $m, Money->new( usd => 1 ), 'took $1 out';
is $purse->amount( 'usd' ), 1, 'got $1 left'
}
It's not nonsensical because it allows you to write more isolated
tests - which can give you more focused test results. If I keep my
tests isolated then one test failing isn't going to make the whole
script fail, and I can easily tweak tests early on in the script
without worrying that it'll change test results further on.
Cheers,
Adrian
