Hi all,
I finally found a spare couple of days to clean up the APIs and write
some docs for the class based testing code I mentioned several months
ago when I was annoying the group with Test::Exception.
The resulting Test::Class module can be found at:
http://www.quietstars.com/perl/
It allows you to create xUnit style testing classes using the
Test::Builder based modules, for example:
package Example::Test;
use base qw(Test::Class);
use Test::More;
# setup methods are run before every test method.
sub make_fixture : Test(setup) {
my $array = [1, 2];
shift->{test_array} = $array;
diag("array = (@$array) before test(s)");
};
# a test method that runs 1 test
sub test_push : Test {
my $array = shift->{test_array};
push @$array, 3;
is_deeply($array, [1, 2, 3], 'push worked');
};
# a test method that runs 4 tests
sub test_pop : Test(4) {
my $array = shift->{test_array};
is(pop @$array, 2, 'pop = 2');
is(pop @$array, 1, 'pop = 1');
is_deeply($array, [], 'array empty');
is(pop @$array, undef, 'pop = undef');
};
# teardown methods are run after every test method.
sub teardown : Test(teardown) {
my $array = shift->{test_array};
diag("array = (@$array) after test(s)");
};
You run the tests like this:
Example::Test->runtests;
Why another module instead of Test::Unit or Test::SimpleUnit?
- Test::SimpleUnit, while cute, was too simple for my needs. I
needed to inherit tests to remove code duplication. Also didn't
mix with Test::Builder and was therefore a harder target for
refactoring existing *.t scripts and modules. (I also have
AnAversionToStudlyCaps in perl :-)
- Test::Unit is a pretty straight port of JUnit into perl. This
gives you good things (familiarity for JUnit users, separate
TestRunners, etc.) and bad things (hard to refactor existing *.t
scripts since they have such a different underlying mechanism,
*lots* of new modules to learn, etc.)
My main goal in writing Test::Class was, of course, to make testing my
code easier. Looking at the result of refactoring my tests, that
turned out to be:
1) Having the minimal of new features beyond Test::More et al.
2) Making it as easy as possible to refactor from *.t scripts to
Test::Class classes.
3) Be pretty easy to get your head around if you are already
familiar with xUnit style testing.
I've tried very hard to make it easy to refactor *.t scripts into
Test::Class classes. You don't have to switch to a different assertion
style for the tests. You don't have to re-write an entire script into
a Test::Class in one go. Etc.
A few specific questions:
0) Do other people find this vaguely sane? Even <gasp> possibly useful?
1) Is Test::Class the right name?
Other names that have been considered during development have been
Class::Test, Test::Attribute, Attribute::Test and Test::Case.
I avoided variants on Unit since:
a) there are already Test::Unit and Test::SimpleUnit and adding
another one would confuse the world even more.
b) I also tend to use it for acceptance/functional tests
However, not having Unit in the name means that people looking for
perlish xUnit testing aren't going to find it :-) Suggestions before I
throw it at CPAN are welcome.
2) You can have multiple setup/teardown methods. This fell out of the
implementation, rather than being a deliberate design decision, but it
has proved surprisingly useful (e.g. have one teardown method to clean
up resources, another to check that class invarients still hold). Is
there some reason why this is evil?
3) The fact that num_method_tests() uses the class it was called from,
rather that the one it was applied to, seems kind of gnarly. However,
it did seem the neatest solution to the inheritance problem mentioned
in the documentation. How offensive do people find this, and is there
a better solution?
The obvious alternative (you supply the package of the method you want
to affect) makes refactoring harder since you have to remember to
update the package name.
Anyway.... comments/niggles/abuse welcome.
Cheers,
Adrian
--
Adrian Howard <[EMAIL PROTECTED]>
phone: 01929 550720 fax: 0870 131 3033 www.quietstars.com
