Re: [Perlunit-devel] compile errors and Loader

[Adam S. <ad...@sp...>]

Adam Spiers (ad...@sp...) wrote:
> 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.

I was wrong about this, it works fine.

> 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.

Done and committed!  This turned out to be a relatively small change
which IMHO made the TestSuite code substantially clearer and simpler,
and I think should also pave the way towards big improvements in how
we can build suites.  More to come on that soon.  I didn't rename all
suite() methods to test_suite(), so the old API should still work
perfectly.  Please test ...

> 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 had the idea of creating a TestCase::_singleton class, so at
run-time the fragments could be blessed into a class which would
inherit from this, but then I realised that this would mean either
changing @MyTestCase::ISA dynamically, which is too awful to
contemplate, or ending up with the fragments not being blessed into
MyTestCase, which isn't nice either.  Hmm, maybe they could be blessed
into MyTestCase::_singleton which ISA MyTestCase; that would be the
best of both worlds?