perlunit-devel — PerlUnit development mailing list

[Perlunit-devel] assert.pm not 100%

[Hans D. <co...@po...>]

Hi there,

Im in the proces of using PerlUnit for an OO-aaplication.
While doing so, I encountered a problem with the Assert.pm.

I think Ive localised it.

At the  elsif (eval {$assertion->isa( UNIVERSAL )} ) {

a require Test::Unit::Assrtion::Boolean; is missing.

_

  Greetings,
  Hans Donner

Re: [Perlunit-devel] Is this thing on?

[Piers C. <pdc...@bo...>]

Adam Spiers <ad...@sp...> writes:

> Piers Cawley (pdc...@bo...) wrote:
>> Adam Spiers <ad...@sp...> writes:
>> > In the absence of any serious activity on HEAD, I think it will make
>> > sense for me to play around with your branch, and base my
>> > modifications over the next week or two on it (maybe I'll even branch
>> > off your branch so I can commit stuff for you to play with?).  Then we
>> > could consider getting it all merged back into HEAD for the next
>> > release before huge branch divergence rears its ugly head and starts
>> > causing big problems?  Of course, what to release is Christian's call
>> > at the end of the day.
>> 
>> Actually, I think the branch is in a fairly ugly state at the moment.
>> I have the horrible feeling I screwed up creating it, but I'm actually
>> using (slightly doctored )branch code in a live project and it's
>> feeling good.
> 
> It doesn't seem too bad.  After fixing a bareword problem (committed),
> t/all_tests and t_assert pass OK.  I was also getting warnings from
> TestCase::to_string, called from Exception::stringify, which were
> fixed by this:
> 
> --- TestCase.pm.~1.19.4.9.~	Thu Oct 25 16:03:34 2001
> +++ TestCase.pm	Fri Oct 26 17:03:54 2001
> @@ -79,7 +79,7 @@
>  sub to_string {
>      my $self = shift;
>      my $class = ref($self);
> -    return $self->name() . "(" . $class . ")";
> +    return $self->name() ? $self->name() . "(" . $class . ")" : $class;
>  }
>  
>  sub make_test_from_coderef {
> 
> Haven't committed this though, as I'm not sure whether it hides
> badness or not.  Should $self->{_name} be initialised at that point?
> Also, if you raise an exception from within to_string(), you get
> infinite recursion, although in this context to_string() is probably
> already being called by exception-handling code, so I guess that's
> inevitable.
> 
> I'm also getting a failure from t/try_examples:
> 
>   not ok 5
>   # Test 5 got: 'TEST-RUN-SUMMARY
>   # TIME-SUMMARY
>   #
>   # OK (3 tests)
>   # ' (t/try_examples.t at line 81)
>   #   Expected: 'Can't call method "run" on an undefined value at lib/Test/Unit/TestRunner.pm line 58.
>   # '
> 
> I think that's examples/patch100132.  Why is it expecting that error?
> Replacing the guru_checked value with a pass like the other two values results in
> 
> t/all_tests.........ok
> t/assert............ok
> t/try_examples......NOK 3Skipping example file 'examples/fail_example.pm', no guru-checked answer
> t/try_examples......ok
> All tests successful.
> 
> Hooray!  :-)
> 
> Did you have any other concerns with the branch that I should know
> about before starting hacking on it?

Not sure now. Nothing's leaping to mind.

> 
>> The naming's still ugly though...
>> 
>> T::U::UnitHarness
>> T::U::HarnessUnit
>> 
>> What were we thinking?
> 
> Yeah, that is pretty bad.

Quite, quite *staggeringly* awful. I'm pleased to say it was like that
when I arrived, nothing to do with me squire and all that...

By the way, I think we're going to have to start playing the name of
the game. From talking to Mike Schwern at YAPC::Europe, it was obvious
that there was some confusion about what PerlUnit was, compounded by
the belief that Test/Unit.pm was the 'main' interface, rather than
some syntactic sugar we bolted on the side.

-- 
Piers

   "It is a truth universally acknowledged that a language in
    possession of a rich syntax must be in need of a rewrite."
         -- Jane Austen?

Re: [Perlunit-devel] Test::Unit/PerlUnit refactoring on branch PDC_REFACTOR

[Piers C. <pdc...@bo...>]

Adam Spiers <ad...@sp...> writes:

> Piers Cawley (pdc...@it...) wrote:
>> [This is posted to both the perl-qa and the perlunit-devel lists]
>> 
>> Okay, I've just checked in a new branch of the Test::Unit CVS with
>> some fairy serious changes in place. Here's the CVS log entry.
>> 
>> ---snip---
>> Beginnings of a major refactoring.
>> 
>> 1. Replace Test::Unit::InnerClass with Class::Inner
> 
> There are still references to Test::Unit::InnerClass; I guess you know
> about those.

Well, actually, I have the feeling that the code in my home directory
that went west didn't have any references to Test::Unit::InnerClass
(and maybe had some more tests as well...). Tell you what, lets just
fix what's in the repository...

>> 4. Also includes an attempt at an 'assert_equals' that does the right
>>    thing in most cases. Tries to make reasonable guesses about numeric or
>>    string comparison, and can make use of object based equality things.
> 
> <random_idea>
> 
> If we're going to be using Attribute::Handlers, it wouldn't be much
> more work to use Attribute::Util and do
> 
>  sub assert_equals : Alias(ok)
> 
> although IIRC some people don't want an ok() in the core framework,
> and it would introduce more module dependencies (not that we've
> shirked away from using other CPAN stuff so far).
> 
> If we did go down that road, Attribute::Protected is pretty sweet too.
> Maybe not enough gain for the extra hassle though?

I confess that I don't like the 'ok' approach to testing, but that's
purely a gut thing.

> </random_idea>
> 
>> I've also been thinking about test 'metadata', ie skiplists and the
>> like, and a little light went on:
>> 
>> sub test_something : todo {...}
>> sub test_something : skip_if(<condition>) {...}
>> sub test_something : skip {...}
>> 
>> TestRunners can take (or not take) notice of this information. Time to
>> investigate Attribute::Handlers methinks.
> 
> Ooh ooh nice idea!  I posted a patch implementing of skiplists (I
> called them filters) to this list on 5th March (subject "PATCH: adding
> state to the runner(s)"), but using Attribute::Handlers is a lovely
> way of tagging tests.  I can get cracking on this on Monday or
> Tuesday.  Shall I branch off your branch, or commit directly to it?

Oh, commit directly to it. I'm not going to be doing any working on it
this weekend (if I'm doing anything I'll be using it to write an
initial few tests for the refactoring browser I'm toying with...)

> 
>> Wanted:
>>
>> Reports from Devel::Cover.
> 
> Nice idea!  Hadn't seen that before.
> 
> Piers Cawley (pdc...@it...) wrote:
>> Right, I've made a whole load more changes on the PDC_REFACTOR branch.
>> Some nice stuff there, though I do say so myself. All the tests are
>> passing here (except for the try_examples.t, which has been failing
>> for a while anyway I believe).
> 
> Oops, saw that too late.  Can anyone say whether my proposed change to
> %guru_checked (see last post) is right or not?
> 
>> No work yet done on Skip/Todo stuff, though I've got a couple of ideas
>> in that direction. I'm quite keen on tests being able to throw
>> 'Test::Unit::Skip' exceptions, which the TestRunner will be able to
>> recognize.
> 
> Would that be as part of or in addition to the test attributes
> scheme?

I think it could well be in addition to. Very often a test can only
know that it should be skipped at runtime, so throwing a skip
exception makes more sense than the programmer deciding when he writes
the test that it should be skipped.

>> This doesn't really work with TODO type tests though...
> 
> Why's that, because TODO tests have to be run to make sure they don't
> succeed, or some other reason?

Because you know you're expecting the test to fail when you write it.
Deciding *at runtime* that the test is going to fail, well, it seems
to go against the grain somehow.

>> Check out Test::Unit::tests::AssertTest for what I think is the
>> beginnings of a neat approach to Results Matrix based testing.
> 
> Looks nice.

Actually, the more I look at that particular example, the more I find
myself thinking that it's over complex. Some kind of results matrix
thing is definitely a good idea, but I'm not sure that what I've got
is it.

>> I'm thinking of splitting Test::Unit::TestCase into
>> Test::Unit::TestCase::Simple, which doesn't do any reflection stuff at
>> all, just uses run_test, and Test::Unit::TestCase::Heavy, which will
>> provide list_tests and other reflective type stuff. Right now there's
>> a certain brainwarping effect when you find yourself dealing with a
>> class that seems to get used in two rather different ways.
> 
> Yeah.  I'm all for keeping classes simple too.

Hence my misgivings about the test matrix stuff. 

-- 
Piers

   "It is a truth universally acknowledged that a language in
    possession of a rich syntax must be in need of a rewrite."
         -- Jane Austen?

Re: [Perlunit-devel] Test::Unit/PerlUnit refactoring on branch PDC_REFACTOR

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

Piers Cawley (pdc...@it...) wrote:
> [This is posted to both the perl-qa and the perlunit-devel lists]
> 
> Okay, I've just checked in a new branch of the Test::Unit CVS with
> some fairy serious changes in place. Here's the CVS log entry.
> 
> ---snip---
> Beginnings of a major refactoring.
> 
> 1. Replace Test::Unit::InnerClass with Class::Inner

There are still references to Test::Unit::InnerClass; I guess you know
about those.

> 4. Also includes an attempt at an 'assert_equals' that does the right
>    thing in most cases. Tries to make reasonable guesses about numeric or
>    string comparison, and can make use of object based equality things.

<random_idea>

If we're going to be using Attribute::Handlers, it wouldn't be much
more work to use Attribute::Util and do

 sub assert_equals : Alias(ok)

although IIRC some people don't want an ok() in the core framework,
and it would introduce more module dependencies (not that we've
shirked away from using other CPAN stuff so far).

If we did go down that road, Attribute::Protected is pretty sweet too.
Maybe not enough gain for the extra hassle though?

</random_idea>

> I've also been thinking about test 'metadata', ie skiplists and the
> like, and a little light went on:
> 
> sub test_something : todo {...}
> sub test_something : skip_if(<condition>) {...}
> sub test_something : skip {...}
> 
> TestRunners can take (or not take) notice of this information. Time to
> investigate Attribute::Handlers methinks.

Ooh ooh nice idea!  I posted a patch implementing of skiplists (I
called them filters) to this list on 5th March (subject "PATCH: adding
state to the runner(s)"), but using Attribute::Handlers is a lovely
way of tagging tests.  I can get cracking on this on Monday or
Tuesday.  Shall I branch off your branch, or commit directly to it?

> Wanted:
>
> Reports from Devel::Cover.

Nice idea!  Hadn't seen that before.

Piers Cawley (pdc...@it...) wrote:
> Right, I've made a whole load more changes on the PDC_REFACTOR branch.
> Some nice stuff there, though I do say so myself. All the tests are
> passing here (except for the try_examples.t, which has been failing
> for a while anyway I believe).

Oops, saw that too late.  Can anyone say whether my proposed change to
%guru_checked (see last post) is right or not?

> No work yet done on Skip/Todo stuff, though I've got a couple of ideas
> in that direction. I'm quite keen on tests being able to throw
> 'Test::Unit::Skip' exceptions, which the TestRunner will be able to
> recognize.

Would that be as part of or in addition to the test attributes scheme?

> This doesn't really work with TODO type tests though...

Why's that, because TODO tests have to be run to make sure they don't
succeed, or some other reason?

> Check out Test::Unit::tests::AssertTest for what I think is the
> beginnings of a neat approach to Results Matrix based testing.

Looks nice.

> I'm thinking of splitting Test::Unit::TestCase into
> Test::Unit::TestCase::Simple, which doesn't do any reflection stuff at
> all, just uses run_test, and Test::Unit::TestCase::Heavy, which will
> provide list_tests and other reflective type stuff. Right now there's
> a certain brainwarping effect when you find yourself dealing with a
> class that seems to get used in two rather different ways.

Yeah.  I'm all for keeping classes simple too.

Re: [Perlunit-devel] Is this thing on?

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

Piers Cawley (pdc...@bo...) wrote:
> Adam Spiers <ad...@sp...> writes:
> > In the absence of any serious activity on HEAD, I think it will make
> > sense for me to play around with your branch, and base my
> > modifications over the next week or two on it (maybe I'll even branch
> > off your branch so I can commit stuff for you to play with?).  Then we
> > could consider getting it all merged back into HEAD for the next
> > release before huge branch divergence rears its ugly head and starts
> > causing big problems?  Of course, what to release is Christian's call
> > at the end of the day.
> 
> Actually, I think the branch is in a fairly ugly state at the moment.
> I have the horrible feeling I screwed up creating it, but I'm actually
> using (slightly doctored )branch code in a live project and it's
> feeling good.

It doesn't seem too bad.  After fixing a bareword problem (committed),
t/all_tests and t_assert pass OK.  I was also getting warnings from
TestCase::to_string, called from Exception::stringify, which were
fixed by this:

--- TestCase.pm.~1.19.4.9.~	Thu Oct 25 16:03:34 2001
+++ TestCase.pm	Fri Oct 26 17:03:54 2001
@@ -79,7 +79,7 @@
 sub to_string {
     my $self = shift;
     my $class = ref($self);
-    return $self->name() . "(" . $class . ")";
+    return $self->name() ? $self->name() . "(" . $class . ")" : $class;
 }
 
 sub make_test_from_coderef {

Haven't committed this though, as I'm not sure whether it hides
badness or not.  Should $self->{_name} be initialised at that point?
Also, if you raise an exception from within to_string(), you get
infinite recursion, although in this context to_string() is probably
already being called by exception-handling code, so I guess that's
inevitable.

I'm also getting a failure from t/try_examples:

  not ok 5
  # Test 5 got: 'TEST-RUN-SUMMARY
  # TIME-SUMMARY
  #
  # OK (3 tests)
  # ' (t/try_examples.t at line 81)
  #   Expected: 'Can't call method "run" on an undefined value at lib/Test/Unit/TestRunner.pm line 58.
  # '

I think that's examples/patch100132.  Why is it expecting that error?
Replacing the guru_checked value with a pass like the other two values results in

t/all_tests.........ok
t/assert............ok
t/try_examples......NOK 3Skipping example file 'examples/fail_example.pm', no guru-checked answer
t/try_examples......ok
All tests successful.

Hooray!  :-)

Did you have any other concerns with the branch that I should know
about before starting hacking on it?

> The naming's still ugly though...
> 
> T::U::UnitHarness
> T::U::HarnessUnit
> 
> What were we thinking?

Yeah, that is pretty bad.

Re: [Perlunit-devel] Is this thing on?

[Piers C. <pdc...@bo...>]

Adam Spiers <ad...@sp...> writes:

> Piers Cawley (pdc...@it...) wrote:
>> *taps glass*
> 
> Sorry for the long delay, I've been suffering from lack of spare time
> just like everyone else here it seems.  Anyway, I'm back now :-)
> 
>> Okay, if anyone's actually listening, I've just had a renaming fest in
>> the PDC_REFACTOR branch. A whole bunch of those Test::Unit::TestFoo
>> classes have become Test::Unit::Foo. Staying in place we have:
>> 
>> Test::Unit::TestRunner, Test::Unit::TkTestRunner,
>> Test::Unit::TestSuite and Test::Unit::TestCase.
>> 
>> Please, check stuff out, take a look, play with it, let me know I'm
>> not just doing this in a vacuum.
> 
> Cool stuff Piers, I like the sound of everything you've done in this
> branch so far.
> 
> In the absence of any serious activity on HEAD, I think it will make
> sense for me to play around with your branch, and base my
> modifications over the next week or two on it (maybe I'll even branch
> off your branch so I can commit stuff for you to play with?).  Then we
> could consider getting it all merged back into HEAD for the next
> release before huge branch divergence rears its ugly head and starts
> causing big problems?  Of course, what to release is Christian's call
> at the end of the day.

Actually, I think the branch is in a fairly ugly state at the moment.
I have the horrible feeling I screwed up creating it, but I'm actually
using (slightly doctored )branch code in a live project and it's
feeling good. You're right about lack of time though. I've just
started work again, and whilst it is, in part, driving what I need
from PerlUnit, it's also chewing up my time. (As is the article I
wrote for perl.com about Perl 6)

> 
> My todo list, IIRC (it's been a while):
>
>   - Incorporate my T::U::Runner class patch that I posted on 5 March (!)
>     That gives us a proper place to store runner state.
> 
>   - Incorporate my patch for improving error messages when a test case
>     class fails to compile (currently just says "not found", which is
>     very misleading).
> 
>   - Address my concerns with the current lack of inheritance of users'
>     test suites from T::U::TestSuite (see March 7th post, subject
>     "TestSuite inheritance and runner state").
> 
>   - Might be worth renaming to T::U::Suite while I'm at it?  I do like
>     the renaming that Piers (and others?) have done along these lines
>     so far.  Hmm, maybe not, given that my T::U::Runner patch already
>     results in two classes T::U::Runner and T::U::TestRunner with
>     distinct roles.

The naming's still ugly though...

T::U::UnitHarness
T::U::HarnessUnit

What were we thinking?

>   - Get test coverage reports working really nicely.  I aim for
>     per-package coverage reports, and per-method reports within each
>     package too.
> 
> Any comments?

See above.

-- 
Piers

   "It is a truth universally acknowledged that a language in
    possession of a rich syntax must be in need of a rewrite."
         -- Jane Austen?

Re: [Perlunit-devel] broken base.pm

[<le...@ai...>]

Adam Spiers <ad...@sp...> writes:

> Regarding what to do about broken old base.pms ...

Is this problem still there? I think I fixed that one by adding
an additional use statement in Test::Unit::Assertion::Boolean, see:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/perlunit/src/Test-Unit/lib/Test/Unit/Assertion/Boolean.pm.diff?r1=1.2&r2=1.3

> 
> Piers Cawley (pdc...@bo...) wrote:
> > Adam Spiers <ad...@sp...> writes:
> > > Nasty, isn't it?  Possible workarounds:
> > > 
> > >  1. Document it
> > >  2. Get `make install' to check for the brokenness and warn
> > >  3. Add `use Foo;' before every `use base qw(Foo);'
> > >  4. Provide a patch
> > > 
> > > 3. is the easiest but somehow I don't like it.
> 
> Nor me.
> 
> > 5. Don't use base at all, do:
> > 
> >     use vars qw/@ISA/;
> >     use Foo ();
> >     @ISA = 'Foo';
> > 
> > After all, it's worked for ages. Ugly though.
> 
> Yeah, really ugly :-(
> 
> > Or, in Makefile.PL:
> > 
> >     use ExtUtils::MakeMaker;
> > 
> >     # See lib/ExtUtils/MakeMaker.pm for details of how to influence
> >     # the contents of the Makefile that is written.
> > 
> >     my $PREREQ_PM;
> >     unless (eval "require 5.6.0") {
> >         $PREREQ_PM = {Class::Fields => 0};
> >     }
> >     else {
> >         $PREREQ_PM = {base => 0};
> >     }
> >      
> >     WriteMakefile(
> >         'NAME'         => 'Test::Unit',
> >         'VERSION_FROM' => 'lib/Test/Unit.pm', # finds $VERSION
> >         'PREREQ_PM'    => $PREREQ_PM,
> >     );
> > 
> > Admittedly, this assumes that the 'base' in Class::Fields on CPAN has
> > the bugfix, which someone (without perl 5.6.0) needs to check.
> 
> I like this approach.  It's the least intrusive, allows us to use nice
> syntax, and is mostly transparent to users.
> 
> Christian Lemburg (le...@ai...) wasn't convinced though:
> > Why rely on that? Where will it break next?
> 
> Nowhere.  I've been using the fixed version for ages, and it's fine.
> The new syntax is much nicer, and I wouldn't like to fight the natural
> course of progress just because of a mistake made in the past.
> 
> Matthew Astley (mc...@us...) suggested:
> > Another solution, can the makefile figure out from the version number
> > of base.pm whether you're running on a broken system or not, and apply
> > 
> >   find blib -name '*.pm' | \
> >   xargs perl -i -pe 's{^\s*use\s+base\s+(.+)} \
> >   {use $1 use vars (\@ISA); \@ISA = $1} .. 0'
> > 
> > to fix the problem? (I, um, changed it after I tested it...)
> 
> Self-modifying code!  I'd really rather avoid that if at all possible,
> we're not in the Dark Ages any more ;-)
> 
> _______________________________________________
> Perlunit-devel mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perlunit-devel

Re: [Perlunit-devel] TestSuite inheritance and runner state

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

Matthew Astley (mc...@us...) wrote:
> On Wed, Apr 25, 2001 at 08:59:50PM +0100, Adam Spiers wrote:
> > Any thoughts on my proposed redesign of TestSuites?  In case you
> > missed it, it was posted on March 7th, subject "TestSuite inheritance
> > and runner state"
> >
> > I proposed that we ditch this
> > 
> >   package My::TestSuites::Foo;
> > 
> >   sub suite {
> >     my $class = shift;
> > 
> >     my $suite = Test::Unit::TestSuite->empty_new('name of suite');
> > 
> >     use My::TestSuites::Bar;
> >     $suite->add_test(My::TestSuites::Bar->suite());
> > 
> >     use My::TestSuites::Baz;
> >     $suite->add_test(My::TestSuites::Baz->suite());
> > 
> >     return $suite;
> >   }
> > 
> > in favour of
> > 
> >   package My::TestSuites::Foo;
> >   use base qw(Test::Unit::TestSuite);
> > 
> >   sub name { 'name of suite' }
> >   sub subsuites { qw(My::TestSuites::Bar My::TestSuites::Baz) }
> > 
> > which is a hell of a lot easier to read, write, and implement the
> > framework for.  It also means that My::TestSuites::Bar really ISA
> > TestSuite.  It never used to be, which seems rather ridiculous.
> 
> You're right, it's much better. Except, can we keep either the suite()
> method or have a call to new() instead please? I do some stuff at
> suite creation time. I could do it before starting the tests, but not
> if the tests are started with the (Tk)?TestRunner.pl provided with
> Perlunit.

Couldn't you do it by overriding new() in your suite?

> Test::Unit::Suite instead of Test::Unit::TestSuite would make a lot of
> sense, and shouldn't break too much stuff since it only occurs at the
> top-ish levels.
> 
> Presumably there'd be defaults
>  T:U::Suite::name { return ref(shift()) }
>  T:U::Suite::subsuites { () }
> ?

Yes.

> Maybe we should have a client-side changelog? Listing things you'll
> need to do to your test code when you upgrade to the next release.
> Seems like a lot of effort though.

Aye, losing backwards compatibility is a concern here.  Maybe we can
keep it with something like

  if ($classname->can('suite')) {
    ...
  }
  elsif ($classname->can('new')) {
    ...
  }
  else {
    die "uhoh";
  }

Without thinking about it too carefully, this default might be
sensible too:

  T::U::Suite::suite { $_[0] }

Sounds OK?

Re: [Perlunit-devel] Is this thing on?

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

Piers Cawley (pdc...@it...) wrote:
> *taps glass*

Sorry for the long delay, I've been suffering from lack of spare time
just like everyone else here it seems.  Anyway, I'm back now :-)

> Okay, if anyone's actually listening, I've just had a renaming fest in
> the PDC_REFACTOR branch. A whole bunch of those Test::Unit::TestFoo
> classes have become Test::Unit::Foo. Staying in place we have:
> 
> Test::Unit::TestRunner, Test::Unit::TkTestRunner,
> Test::Unit::TestSuite and Test::Unit::TestCase.
> 
> Please, check stuff out, take a look, play with it, let me know I'm
> not just doing this in a vacuum.

Cool stuff Piers, I like the sound of everything you've done in this
branch so far.

In the absence of any serious activity on HEAD, I think it will make
sense for me to play around with your branch, and base my
modifications over the next week or two on it (maybe I'll even branch
off your branch so I can commit stuff for you to play with?).  Then we
could consider getting it all merged back into HEAD for the next
release before huge branch divergence rears its ugly head and starts
causing big problems?  Of course, what to release is Christian's call
at the end of the day.

My todo list, IIRC (it's been a while):

  - Incorporate my T::U::Runner class patch that I posted on 5 March (!)
    That gives us a proper place to store runner state.

  - Incorporate my patch for improving error messages when a test case
    class fails to compile (currently just says "not found", which is
    very misleading).

  - Address my concerns with the current lack of inheritance of users'
    test suites from T::U::TestSuite (see March 7th post, subject
    "TestSuite inheritance and runner state").

  - Might be worth renaming to T::U::Suite while I'm at it?  I do like
    the renaming that Piers (and others?) have done along these lines
    so far.  Hmm, maybe not, given that my T::U::Runner patch already
    results in two classes T::U::Runner and T::U::TestRunner with
    distinct roles.

  - Get test coverage reports working really nicely.  I aim for
    per-package coverage reports, and per-method reports within each
    package too.

Any comments?

Re: [Perlunit-devel] broken base.pm

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

Regarding what to do about broken old base.pms ...

Piers Cawley (pdc...@bo...) wrote:
> Adam Spiers <ad...@sp...> writes:
> > Nasty, isn't it?  Possible workarounds:
> > 
> >  1. Document it
> >  2. Get `make install' to check for the brokenness and warn
> >  3. Add `use Foo;' before every `use base qw(Foo);'
> >  4. Provide a patch
> > 
> > 3. is the easiest but somehow I don't like it.

Nor me.

> 5. Don't use base at all, do:
> 
>     use vars qw/@ISA/;
>     use Foo ();
>     @ISA = 'Foo';
> 
> After all, it's worked for ages. Ugly though.

Yeah, really ugly :-(

> Or, in Makefile.PL:
> 
>     use ExtUtils::MakeMaker;
> 
>     # See lib/ExtUtils/MakeMaker.pm for details of how to influence
>     # the contents of the Makefile that is written.
> 
>     my $PREREQ_PM;
>     unless (eval "require 5.6.0") {
>         $PREREQ_PM = {Class::Fields => 0};
>     }
>     else {
>         $PREREQ_PM = {base => 0};
>     }
>      
>     WriteMakefile(
>         'NAME'         => 'Test::Unit',
>         'VERSION_FROM' => 'lib/Test/Unit.pm', # finds $VERSION
>         'PREREQ_PM'    => $PREREQ_PM,
>     );
> 
> Admittedly, this assumes that the 'base' in Class::Fields on CPAN has
> the bugfix, which someone (without perl 5.6.0) needs to check.

I like this approach.  It's the least intrusive, allows us to use nice
syntax, and is mostly transparent to users.

Christian Lemburg (le...@ai...) wasn't convinced though:
> Why rely on that? Where will it break next?

Nowhere.  I've been using the fixed version for ages, and it's fine.
The new syntax is much nicer, and I wouldn't like to fight the natural
course of progress just because of a mistake made in the past.

Matthew Astley (mc...@us...) suggested:
> Another solution, can the makefile figure out from the version number
> of base.pm whether you're running on a broken system or not, and apply
> 
>   find blib -name '*.pm' | \
>   xargs perl -i -pe 's{^\s*use\s+base\s+(.+)} \
>   {use $1 use vars (\@ISA); \@ISA = $1} .. 0'
> 
> to fix the problem? (I, um, changed it after I tested it...)

Self-modifying code!  I'd really rather avoid that if at all possible,
we're not in the Dark Ages any more ;-)