On 25 Jun 2004, at 16:51, Fergal Daly wrote: [snip]
NB: I haven't used xUnit style testing so I could be completely off the mark
but some (not all) of these benefits seem to be available in T::M land.
Just so I'm clear - I'm /not/ saying any of this is impossible with T::M and friends. That's obviously silly since you can build an xUnit framework with Test::Builder and friends.
What xUnit gives you is a little bit more infrastructure to make these sorts of task easier.
Off the top of my head.
* I never have to type repetitive tests like
isa_ok Foo->new(), 'Foo'
again because it's handled by a base class that all my test classes inherit from.
sub constructor_ok { my $class = shift;
isa_ok $class->new, $class; }
But you still have to call constructor_ok().
I can still all my common tests in a base test class and just by inheriting from it get them all run automagically.
* I can create units of testing that can be reused multiple times. If I
have an Iterator interface I can write a test suite for it once and
reuse it any class that implements the Iterator interface.
What's stopping you doing this in T::M,
sub test_iterator { my $iterator = shift; # test various things about $iterator. }
Nothing. But xUnit supplies a little extra bit of magic to mark 'test' subroutines so they can be automatically found and run with no effort on your part.
* I have conception level available higher than individual tests (in T::M land) or asserts (in xUnit land). I can say something like:
sub addition_is_commutative : Test { is 10 + 5, 15; is 5 + 10, 15; };
and talk about addition_is_commutative test as a concept separate from the tests/assertions that implement it. I can easily move test methods around as I refactor without having to worry about it breaking some other part of the test suite.
I don't get this. What is the difference between having this as a method vs as a sub?
By having it as a test method it gets automatically picked up and run by the test environment. I can move the test method to another class and, without altering another line, it will be automatically picked up and run by the new class.
* The setup/teardown methods provide an infrastructure for creating test fixtures and isolating tests, which can often save typing and speed everything up considerably.
* Need to check that a class invariant still holds after each test? Chuck it in a teardown method.
The T::M land you could put your setup and teardown in modules and call them before and after. Then if they're named consistently you could automate that at which point, you'd almost have xUnit. So xUnit seems to win here for sure,
Exactly! This is all stuff that Test::Builder based modules can do - xUnit just sprinkles some convenience fairy dust over everything to make doing it easier :-)
The /nice/ thing about Perl's infrastructure is that we can abandon the extra infrastructure when we don't need it - making simpler test scripts more compact and easier to understand.
Cheers,
Adrian
