Piers Cawley ([EMAIL PROTECTED]) wrote:
> I can cope with this project management malarkey. You get to tell
> people what needs doing, and it gets done. I'm not sure I've written a
> line of code since I bought the maintainer's hat.
;-)
> I intend to rectify that this weekend.
Cool. If you end up looking into the mess I was moaning about
concerning test suites and test cases etc., you may be interested in
the discussion I just had with my cow-orker. We looked at the JUnit
and PerlUnit code and documented APIs, read some of the introductory
papers Kent Beck et al. wrote on the framework, and came up with the
following conclusions:
Problem 1:
In JUnit, you can do
TestSuite suite= new TestSuite();
suite.addTest(new MoneyTest("testMoneyEquals"));
where MoneyTest extends TestCase. In PerlUnit, this does not work
(for me, at least):
my $suite = Test::Unit::TestSuite->empty_new();
$suite->add_test(MoneyTest->new("testMoneyEquals"));
where MoneyTest ISA Test::Unit::TestCase. I don't see any
documentation which suggests it should work, but from looking at the
code, it seems it should work. Maybe just a bug somewhere? Needs to
be fixed before 1.0.
Problem 2:
In PerlUnit, there is no way of creating a new suite by inheriting
from Test::Unit::TestSuite. This means that all TestSuites are
"anonymous" instances of the Test::Unit::TestSuite class itself,
i.e. they're not blessed into the relevant package. That means that
there's currently no way of retrieving the name of the package which
built the suite. Baaaaad.
Solution:
Rewrite new() and empty_new() to support proper inheritance, while
still allowing the old suite() method way. Actually, the old way only
makes sense when embedding tests within the classes they are testing,
so really it should be renamed to test_suite(). This solution
involves API changes, so needs to be done before 1.0.
Problem 3:
To our eyes, the JUnit API and design which PerlUnit copies is
fundamentally confusing in its definition of `test case'. It states
that a test case is a series of test methods with some fixture, but
during the method extraction phase of building of a suite, something
funny happens: the test case is "fragmented" into multiple instances
of itself, each one containing a single method (once for each test
method in the test case), and each one also containing the same
fixture as the original multi-test test case. To compound the
confusion, those fragmented test cases are then collated into a test
suite.
In other words, the object hierarchy that the end user understands and
to a certain extent constructs, does *not* correspond to the object
hierarchy which is operated on by the framework code at test runtime.
The user thinks of groups of test methods with common fixture, and
presumably calls such a group a `test case'. However, the framework
code ends up running a group of test methods as a test suite which
contains test case singletons or "fragments". This happens behind the
scenes, so it's not a disaster for the user, but this failure to
distinguish between singleton test cases and test case groups is a
PITA for framework developers (well, it confused the hell out of us
two at least).
Solution:
The XUnit design has probably been around too long to be able to do
much about this other than make sure it's well documented :-(
I'm out of time. I hope that eliminated confusion rather than
increased it ...
_______________________________________________
Perlunit-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/perlunit-devel
