On Fri, Jun 25, 2004 at 04:05:09PM +0100, Adrian Howard wrote:
>
> On 24 Jun 2004, at 20:19, Andrew Pimlott wrote:
>
> >On Thu, Jun 24, 2004 at 05:08:44PM +0100, Adrian Howard wrote:
> >>Where xUnit wins for me are in the normal places where OO is useful
> >>(abstraction, reuse, revealing intention, etc.).
> >
> >Since you've thought about this, and obviously don't believe "it's OO
> >so
> >it's better", I'd be interested in seeing an example if you have one in
> >mind.
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.
> 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;
}
> * 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.
}
> * 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?
> * 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,
F
