perlunit-devel — PerlUnit development mailing list

[Perlunit-devel] Class::Inner

[Philip K. <em...@ch...>]

Seems pretty sketchy for Unit::Test to depend on 0.1
software (Class::Inner).  There has been *one* release,
and that was over a year ago.  Come on, folks...

Here is my "make test" for Class::Inner.
PERL_DL_NONLAZY=1 /usr/local/bin/perl -Iblib/arch
-Iblib/lib -I/usr/lib/perl/5.6.1
-I/usr/share/perl/5.6.1 -e 'use Test::Harness
qw(&runtests $verbose); $verbose=0; runtests @ARGV;'
t/*.t
t/basic.............FAILED tests 1-13
                           Failed 13/13 tests, 0.00%
                           okay

Failed	13 out of 13 tests!  No thanks, sticking with
older versions of Unit::Test.

(At what point in the enhancements of Unit::Test was it
determined that an alpha implementation of inner classes
was necessary???)

[Perlunit-devel] bug report

[<mic...@sy...>]

Bug in Test::Unit::Procedural

I just upgraded from Test::Unit 0.14 to 0.24.  I only use Test::Unit (now
Test::Unit::Procedural).

tear_down() no longer runs in Test::Unit::Procedural.  set_up() still runs
as expected.

Thank you for the module and fixing this bug whenever you have time,
Michael Peterson

Re: [Perlunit-devel] question of installing PerlUnit

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

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

> Cindy Chen (ci...@re...) wrote:
> > Hi,
> >  
> > I'm trying to install PerlUnit.
> 
> (Please send installation-related queries to perlunit-users in
> future.  Thanks.)
> 
> > But first I have a problem with installing 
> > "Class::Inner". 
> >  
> > I got an error message when running "make test"
> >  
> > ===============================================
> > PERL_DL_NONLAZY=1 /usr/bin/perl -Iblib/arch -Iblib/lib 
> > -I/usr/lib/perl5/5.6.0/i386-linux -I/usr/lib/perl5/5.6.0 -e 'use 
> > Test::Harness qw(&runtests $verbose); $verbose=0; runtests @ARGV;' t/*.t
> > t/basic.............FAILED tests 1-13
> >         Failed 13/13 tests, 0.00% okay
> > Failed Test  Status Wstat Total Fail  Failed  List of failed
> > -------------------------------------------------------------------------------
> > t/basic.t                    13   13 100.00%  1-13
> > Failed 1/1 test scripts, 0.00% okay. 13/13 subtests failed, 0.00% okay.
> > make: *** [test_dynamic] Error 29
> > ===============================================
> 
> I'll leave Piers to deal with questions about Class::Inner.

Err... it works for me. I've come across people having this issue, but
never managed to duplicate it. You couldn't try doing 

 $ perl -Mblib t/basic.t 

from the package's root directory and send me the output could you?


-- 
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] question of installing PerlUnit

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

Cindy Chen (ci...@re...) wrote:
> Hi,
>  
> I'm trying to install PerlUnit.

(Please send installation-related queries to perlunit-users in
future.  Thanks.)

> But first I have a problem with installing 
> "Class::Inner". 
>  
> I got an error message when running "make test"
>  
> ===============================================
> PERL_DL_NONLAZY=1 /usr/bin/perl -Iblib/arch -Iblib/lib 
> -I/usr/lib/perl5/5.6.0/i386-linux -I/usr/lib/perl5/5.6.0 -e 'use 
> Test::Harness qw(&runtests $verbose); $verbose=0; runtests @ARGV;' t/*.t
> t/basic.............FAILED tests 1-13
>         Failed 13/13 tests, 0.00% okay
> Failed Test  Status Wstat Total Fail  Failed  List of failed
> -------------------------------------------------------------------------------
> t/basic.t                    13   13 100.00%  1-13
> Failed 1/1 test scripts, 0.00% okay. 13/13 subtests failed, 0.00% okay.
> make: *** [test_dynamic] Error 29
> ===============================================

I'll leave Piers to deal with questions about Class::Inner.

> If I ignore the error message, continue with "make install", things seem 
> to be ok. No more error messages generated. 
> 
> However, after I installed Devel::Symdump and Tk as well and run the test
> 
> "perl -w -I./lib -I./t/tlib TestRunner.pl AllTests"

You should be running 'make test' instead, as AllTests doesn't
actually contain all the self-tests.  This doesn't explain the errors
you are seeing, however.

> I got another error message as:
> 
> ===============================================
> Subroutine make_new_from_error redefined at 
> /usr/lib/perl5/site_perl/5.6.0/i386-linux/Test/Unit/Error.pm line 8.
> Bareword found where operator expected at t/tlib/ExceptionChecker.pm line 
> 37, near "$exception_class with"
>         (Missing operator before with?)
> .this set_up dies at t/tlib/TestTest.pm line 219.
> ===============================================
> 
> And if I remove "Error.pm" from that directory, I got another message as:
> 
> ===============================================
> Can't locate Test/Unit/Error.pm in @INC (@INC contains: ./lib ./t/tlib 
> /usr/lib/perl5/5.6.0/i386-linux /usr/lib/perl5/5.6.0 
> /usr/lib/perl5/site_perl/5.6.0/i386-linux /usr/lib/perl5/site_perl/5.6.0 
> /usr/lib/perl5/site_perl .) at lib/Test/Unit/Result.pm line 5.
> BEGIN failed--compilation aborted at lib/Test/Unit/Result.pm line 5.
> Compilation failed in require at lib/Test/Unit/Runner.pm line 4.
> BEGIN failed--compilation aborted at lib/Test/Unit/Runner.pm line 4.
> Compilation failed in require at (eval 2) line 3.
>         ...propagated at /usr/lib/perl5/5.6.0/base.pm line 62.
> BEGIN failed--compilation aborted at lib/Test/Unit/TestRunner.pm line 4.
> Compilation failed in require at TestRunner.pl line 6.
> BEGIN failed--compilation aborted at TestRunner.pl line 6.
> ===============================================
> 
> Could you please help me solving the problem? I'm using a LINUX box with 
> Red Hat 7.2 and perl v5.6.0

Very strange.  Which version of PerlUnit are you using?  Please try
0.24 or CVS if you aren't already.

Adam

[Perlunit-devel] question of installing PerlUnit

[Cindy C. <ci...@re...>]

Hi,
 
I'm trying to install PerlUnit. But first I have a problem with installing 
"Class::Inner". 
 
I got an error message when running "make test"
 
===============================================
PERL_DL_NONLAZY=1 /usr/bin/perl -Iblib/arch -Iblib/lib 
-I/usr/lib/perl5/5.6.0/i386-linux -I/usr/lib/perl5/5.6.0 -e 'use 
Test::Harness qw(&runtests $verbose); $verbose=0; runtests @ARGV;' t/*.t
t/basic.............FAILED tests 1-13
        Failed 13/13 tests, 0.00% okay
Failed Test  Status Wstat Total Fail  Failed  List of failed
-------------------------------------------------------------------------------
t/basic.t                    13   13 100.00%  1-13
Failed 1/1 test scripts, 0.00% okay. 13/13 subtests failed, 0.00% okay.
make: *** [test_dynamic] Error 29
===============================================

If I ignore the error message, continue with "make install", things seem 
to be ok. No more error messages generated. 

However, after I installed Devel::Symdump and Tk as well and run the test

"perl -w -I./lib -I./t/tlib TestRunner.pl AllTests"
 
I got another error message as:

===============================================
Subroutine make_new_from_error redefined at 
/usr/lib/perl5/site_perl/5.6.0/i386-linux/Test/Unit/Error.pm line 8.
Bareword found where operator expected at t/tlib/ExceptionChecker.pm line 
37, near "$exception_class with"
        (Missing operator before with?)
.this set_up dies at t/tlib/TestTest.pm line 219.
===============================================

And if I remove "Error.pm" from that directory, I got another message as:

===============================================
Can't locate Test/Unit/Error.pm in @INC (@INC contains: ./lib ./t/tlib 
/usr/lib/perl5/5.6.0/i386-linux /usr/lib/perl5/5.6.0 
/usr/lib/perl5/site_perl/5.6.0/i386-linux /usr/lib/perl5/site_perl/5.6.0 
/usr/lib/perl5/site_perl .) at lib/Test/Unit/Result.pm line 5.
BEGIN failed--compilation aborted at lib/Test/Unit/Result.pm line 5.
Compilation failed in require at lib/Test/Unit/Runner.pm line 4.
BEGIN failed--compilation aborted at lib/Test/Unit/Runner.pm line 4.
Compilation failed in require at (eval 2) line 3.
        ...propagated at /usr/lib/perl5/5.6.0/base.pm line 62.
BEGIN failed--compilation aborted at lib/Test/Unit/TestRunner.pm line 4.
Compilation failed in require at TestRunner.pl line 6.
BEGIN failed--compilation aborted at TestRunner.pl line 6.
===============================================

Could you please help me solving the problem? I'm using a LINUX box with 
Red Hat 7.2 and perl v5.6.0

Thanks!


Cindy Chen 

Re: [Perlunit-devel] anyone with Perl 5.[78].x?

[Jonas B. N. <jo...@wa...>]

Hello,

I experienced test failures under 5.6.0 under OS X for both Class::Inner 
and Test::Unit (probably due the the first problems with Class::Inner).

I looked at the source code, and the tests are written for Test::More, 
so I updated Test::More from CPAN and then everything worked out...

I do not know to what extent Test::More and Test::Simple is bundled with 
Perl, but shouldn't CPAN modules be written for Test, or the 
dependencies for the newer Test::More module be specified in the Perl 
makefile??

I would very much like to conduct a proper test of this and I regret not 
having taken notes during my install, but I just wanted to install the 
stuff and then move on to something else...

I hope this is of use to you?

jonasbn

On Thursday, June 20, 2002, at 05:30 , Adam Spiers wrote:

> This is a plea for help.  I've been told that PerlUnit doesn't pass
> the tests on 5.7.2 or 5.8.0, but I don't have either of those versions
> handy to test with.  If any kind soul has either of them and a small
> bit of spare time, could you try the latest release or CVS code on
> them and let me know what goes wrong?  I'd be really grateful.
>
>
> -------------------------------------------------------
>                    Bringing you mounds of caffeinated joy
>>>>     http://thinkgeek.com/sf    <<<
>
> _______________________________________________
> Perlunit-devel mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perlunit-devel
>

Re: [Perlunit-devel] Suggestions for a PerlUnit conundrum?

[Matthias F. <mf...@hi...>]

On Fri, 21 Jun 2002, Adam Spiers wrote:

> Matthias Ferber (mf...@hi...) wrote:
> > Named pipes have all the same problems as message queues,
unfortunately.
> [snip]
> 
> Difficult to say without seeing the code and understanding more about
> how message queues get left behind.  Can't you do some cleanup in END?

I had to look this up, but unfortunately END doesn't handle the real
problem case, which is when the program goes kaput due to a signal, in
particular if the user hits ctrl-C.  It was a good idea though.

I've been reading about perl 5.8 and the new threading model.  I have some
hopes for that.

The part about how message queues get left behind is actually very simple
and sort of irrelevant.  The concept is exactly the same as if my script
creates a temporary file and deletes it when it's finished.  If the script
is cancelled halfway through, the temporary file doesn't get deleted, and
over time these files will eat up space.

The difference is that temporary files are so common that people have
mechanisms around for dealing with them, and the /tmp directory is a
reasonably safe place to put them.  There's no such thing for IPC
structures, which don't live in the file system.  (I also have a suspicion
that lingering IPC thingies take up more OS resources, but that's only a
guess.)  Either way, this is a tough problem for a reusable library --
unless there's some kind of convention I'm unaware of.

Sigh... hurry up, threads....

Matthias

Re: [Perlunit-devel] Suggestions for a PerlUnit conundrum?

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

Matthias Ferber (mf...@hi...) wrote:
> Named pipes have all the same problems as message queues, unfortunately.
> All three of the main IPC tools -- those two and shared memory -- use OS
> constructs that don't go away on their own.  I chose message queues
> because it's best at handling discrete, sequential messages, which is what
> I needed.
> 
> I handled the problem in the script that runs the test by having it check
> first for existing message queues that may have been left behind by
> unfinished runs in the past and giving the user a chance to delete them.
> It's not perfect, and more to the point it's not (and cannot be) part of
> the test framework.
> 
> So I'm not sure what to with this.  Do you think it's worth considering as
> part of the framework, with a big fat warning or two in the POD?

Difficult to say without seeing the code and understanding more about
how message queues get left behind.  Can't you do some cleanup in END?

Re: [Perlunit-devel] Teensy PerlUnit suggestion, and a question

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

Matthias Ferber (mf...@hi...) wrote:
> I built a script that did something like this for JUnit in Java -- the
> part about controlling which test methods get run, that is, not the part
> about passing arguments, which may be impossible in Java anyway.  I used
> colons as a delimiter:
> 
> java TestRunner class1:test1 class2:test2...
> 
> The colon would be awkward in Perl because it's also used in the class
> delimiter, but another symbol could work:
> 
> perl TestRunner.pl My::Class1.method1 My::Class2.method2

That's quite nice.

> You could extend that to passing arguments, except then you have trouble
> if the argument contains a period (or whatever delimiter).
> 
> This isn't a wholly thought out idea yet, but what I like about it versus
> passing the method names as arguments is that it can be combined with
> passing real arguments.  I'm not sure that holds water yet, though, and
> the method-names-as-arguments idea has the great advantage of being
> intuitive (perhaps except for the --, but that doesn't seem so bad to
> me).  I'm going to try to come up with more ideas and bat this around a
> little more.
> 
> Here's one off the cuff:
> 
> perl TestRunner.pl -switches My::ClassA -m method1 -m method2 My::ClassB
> 
> to test two methods from ClassA and all of ClassB.

or

  perl TestRunner.pl -switches My::ClassA ::method1 ::method2 My::ClassB

It all depends on whether we want to allow arguments other than
methods.  I don't need them myself (yet) but I guess we do want to
allow them.

The other question is whether switches should apply globally or be
allowed as sort of local modifiers for each class, although there's a
danger we're thinking too far ahead here.

Re: [Perlunit-devel] new filtering mechanism, and documentation issues

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

Matthias Ferber (mf...@hi...) wrote:
> I'm a big fan of more documentation vs. less documentation.  The old
> standby, "This function is subject to change in the future, use at your
> own risk," can be a big help in this situation, and will help to
> distinguish the stable parts from the unstable parts.  Yes?

Yep, agreed.

Re: [Perlunit-devel] new filtering mechanism, and documentation issues

[Matthias F. <mf...@hi...>]

I'm a big fan of more documentation vs. less documentation.  The old
standby, "This function is subject to change in the future, use at your
own risk," can be a big help in this situation, and will help to
distinguish the stable parts from the unstable parts.  Yes?

On Thu, 20 Jun 2002, Adam Spiers wrote:

> I just committed a nice filtering enhancement.  From the ChangeLog:
> 
>   - remove ALL filtering hack, and instead allow filtering via coderefs:
> 
>       sub filter {{
>           foo_tests  => sub {
>               my $method = shift;
>               return $method =~ /foo/;
>           },
>           everything => sub { 1 },
> 
>           # method lists still work
>           another_token => [ qw/test_method1 test_method2/ ],
>       }}
> 
> Documentation is slowly improving on the more esoteric stuff too.
> Up till now the classes used internally by the framework have not been
> documented, the idea being that only PerlUnit developers should need
> to understand them.  However it seems to me that it's a far old grey
> area between where the framework stops and where the developer takes
> over, so I've been thinking that maybe the framework should appear
> more open, by being fully documented.  Any opinions?
> 
> 
> -------------------------------------------------------
>                    Bringing you mounds of caffeinated joy
>                    >>>     http://thinkgeek.com/sf    <<<
> 
> _______________________________________________
> Perlunit-devel mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perlunit-devel
> 

Re: [Perlunit-devel] Teensy PerlUnit suggestion, and a question

[Matthias F. <mf...@hi...>]

I built a script that did something like this for JUnit in Java -- the
part about controlling which test methods get run, that is, not the part
about passing arguments, which may be impossible in Java anyway.  I used
colons as a delimiter:

java TestRunner class1:test1 class2:test2...

The colon would be awkward in Perl because it's also used in the class
delimiter, but another symbol could work:

perl TestRunner.pl My::Class1.method1 My::Class2.method2

You could extend that to passing arguments, except then you have trouble
if the argument contains a period (or whatever delimiter).

This isn't a wholly thought out idea yet, but what I like about it versus
passing the method names as arguments is that it can be combined with
passing real arguments.  I'm not sure that holds water yet, though, and
the method-names-as-arguments idea has the great advantage of being
intuitive (perhaps except for the --, but that doesn't seem so bad to
me).  I'm going to try to come up with more ideas and bat this around a
little more.

Here's one off the cuff:

perl TestRunner.pl -switches My::ClassA -m method1 -m method2 My::ClassB

to test two methods from ClassA and all of ClassB.

still thinking...
Matthias


On Thu, 20 Jun 2002, Adam Spiers wrote:

> Matthias Ferber (mf...@hi...) wrote:
> > Thanks for the help, Adam, that's reassuring.  I'm not actually sure
> > whether the syntax I showed as an example would be the best interpretation
> > in practice, actually.  Right now, if I'm reading the code right,
> > TestRunner::start() ignores all but the last argument (not counting
> > switches).  I can see two reasonable ways to change that: one is to take
> > the first non-switch argument as the name of the class to build a suite
> > from and pass the remaining arguments to its constructor, which would
> > handle the situation I'm working on and would look like my example; the
> > other thing it could do is interpret all the arguments as separate test
> > classes, and build a suite combining the suites from each of those
> > classes. 
> > 
> > I like the first idea because it adds flexibility in situations like mine,
> > but the second is perhaps more intuitive and maybe even more useful most
> > of the time.  So I think I'll just throw these both out as possibilities
> > for thought and let 'em fall where they may.
> 
> I've been wanting more control from the command-line recently too,
> which has been a good reason to get off my butt and reply to your mail.
> More specifically, I want to be able to control which test methods in
> a suite get run by passing them as arguments.  The immediate problem
> for me is that I have an equivalent of TestRunner.pl which allows
> running of several suites at once, e.g.
> 
>   $ ./MyTestRunner.pl MySuite1 MySuite2
> 
> but allowing arguments to a suite would break that.  One approach I
> thought of was using '--' to delimit the tests:
> 
>   $ ./TestRunner.pl --switch MyTest1 arg1a arg1b -- MyTest2 arg2a arg2b
> 
> How does that sound?
> 
> It occurs to me that I should probably merge all my runner's
> enhancements back into TestRunner.pl; the latter is a rather lame
> piece of code as it stands.
> 
> > Re TestRunner.pm, if you're going to clean up that part of the code
> > anyway, and if do_run()  is going to be public, may I suggest naming it
> > run_suite() instead for clarity? 
> 
> Good idea; added to doc/TODO.
> 
> 
> -------------------------------------------------------
>                    Bringing you mounds of caffeinated joy
>                    >>>     http://thinkgeek.com/sf    <<<
> 
> _______________________________________________
> Perlunit-devel mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perlunit-devel
> 

Re: [Perlunit-devel] Suggestions for a PerlUnit conundrum?

[Matthias F. <mf...@hi...>]

Whoa... so many issues from the past, all hitting at once.  Reminds me of
a James Hogan story I read once.  Anyway.

Named pipes have all the same problems as message queues, unfortunately.
All three of the main IPC tools -- those two and shared memory -- use OS
constructs that don't go away on their own.  I chose message queues
because it's best at handling discrete, sequential messages, which is what
I needed.

I handled the problem in the script that runs the test by having it check
first for existing message queues that may have been left behind by
unfinished runs in the past and giving the user a chance to delete them.
It's not perfect, and more to the point it's not (and cannot be) part of
the test framework.

So I'm not sure what to with this.  Do you think it's worth considering as
part of the framework, with a big fat warning or two in the POD?

Matthias

On Thu, 20 Jun 2002, Adam Spiers wrote:

> Matthias Ferber (mf...@hi...) wrote:
> > I've written a TestDecorator for PerlUnit that runs the tests in a suite
> > in parallel -- a very useful feature when testing the results of a series
> > of web queries, since they're time consuming.  (I did this a while ago in
> > JUnit, but it was rather easier there thanks to threading.) 
> > 
> > The problem I've hit has to do with the interprocess communication.  I
> > used the Perl built-in interface to SysV message queues -- msgsnd, msgrcv,
> > etc., or rather the SysV::* wrapper classes -- to let the parallel test
> > results be combined into one result set.  The problem is that the message
> > queue or queues created will never get cleaned up if the test is cancelled
> > by the user or crashes; they'll just clutter up the OS.  And trying to
> > trap signals to clean up the mess on exit is, by all accounts, impossible
> > to do reliably and safely. 
> > 
> > Any suggestions from PerlUnitLand?  I'd welcome either practical solutions
> > to this problem, or even suggestions for another approach entirely.  My
> > ulterior motive is that I think this decorator is useful enough to be made
> > public, possibly even bundled with PerlUnit, but I don't want to do that
> > unless it's more robust than this. 
> 
> This sounds like very interesting work which it would be great to
> integrate into the main tree.  Unfortunately my knowledge of IPC is
> very limited so I'm afraid I can't really be of much help.  I don't
> suppose named pipes could be of any use?
> 
> 
> -------------------------------------------------------
>                    Bringing you mounds of caffeinated joy
>                    >>>     http://thinkgeek.com/sf    <<<
> 
> _______________________________________________
> Perlunit-devel mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perlunit-devel
> 

[Perlunit-devel] new filtering mechanism, and documentation issues

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

I just committed a nice filtering enhancement.  From the ChangeLog:

  - remove ALL filtering hack, and instead allow filtering via coderefs:

      sub filter {{
          foo_tests  => sub {
              my $method = shift;
              return $method =~ /foo/;
          },
          everything => sub { 1 },

          # method lists still work
          another_token => [ qw/test_method1 test_method2/ ],
      }}

Documentation is slowly improving on the more esoteric stuff too.
Up till now the classes used internally by the framework have not been
documented, the idea being that only PerlUnit developers should need
to understand them.  However it seems to me that it's a far old grey
area between where the framework stops and where the developer takes
over, so I've been thinking that maybe the framework should appear
more open, by being fully documented.  Any opinions?

[Perlunit-devel] anyone with Perl 5.[78].x?

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

This is a plea for help.  I've been told that PerlUnit doesn't pass
the tests on 5.7.2 or 5.8.0, but I don't have either of those versions
handy to test with.  If any kind soul has either of them and a small
bit of spare time, could you try the latest release or CVS code on
them and let me know what goes wrong?  I'd be really grateful.

Re: [Perlunit-devel] Teensy PerlUnit suggestion, and a question

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

Matthias Ferber (mf...@hi...) wrote:
> Thanks for the help, Adam, that's reassuring.  I'm not actually sure
> whether the syntax I showed as an example would be the best interpretation
> in practice, actually.  Right now, if I'm reading the code right,
> TestRunner::start() ignores all but the last argument (not counting
> switches).  I can see two reasonable ways to change that: one is to take
> the first non-switch argument as the name of the class to build a suite
> from and pass the remaining arguments to its constructor, which would
> handle the situation I'm working on and would look like my example; the
> other thing it could do is interpret all the arguments as separate test
> classes, and build a suite combining the suites from each of those
> classes. 
> 
> I like the first idea because it adds flexibility in situations like mine,
> but the second is perhaps more intuitive and maybe even more useful most
> of the time.  So I think I'll just throw these both out as possibilities
> for thought and let 'em fall where they may.

I've been wanting more control from the command-line recently too,
which has been a good reason to get off my butt and reply to your mail.
More specifically, I want to be able to control which test methods in
a suite get run by passing them as arguments.  The immediate problem
for me is that I have an equivalent of TestRunner.pl which allows
running of several suites at once, e.g.

  $ ./MyTestRunner.pl MySuite1 MySuite2

but allowing arguments to a suite would break that.  One approach I
thought of was using '--' to delimit the tests:

  $ ./TestRunner.pl --switch MyTest1 arg1a arg1b -- MyTest2 arg2a arg2b

How does that sound?

It occurs to me that I should probably merge all my runner's
enhancements back into TestRunner.pl; the latter is a rather lame
piece of code as it stands.

> Re TestRunner.pm, if you're going to clean up that part of the code
> anyway, and if do_run()  is going to be public, may I suggest naming it
> run_suite() instead for clarity? 

Good idea; added to doc/TODO.

Re: [Perlunit-devel] Suggestions for a PerlUnit conundrum?

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

Matthias Ferber (mf...@hi...) wrote:
> I've written a TestDecorator for PerlUnit that runs the tests in a suite
> in parallel -- a very useful feature when testing the results of a series
> of web queries, since they're time consuming.  (I did this a while ago in
> JUnit, but it was rather easier there thanks to threading.) 
> 
> The problem I've hit has to do with the interprocess communication.  I
> used the Perl built-in interface to SysV message queues -- msgsnd, msgrcv,
> etc., or rather the SysV::* wrapper classes -- to let the parallel test
> results be combined into one result set.  The problem is that the message
> queue or queues created will never get cleaned up if the test is cancelled
> by the user or crashes; they'll just clutter up the OS.  And trying to
> trap signals to clean up the mess on exit is, by all accounts, impossible
> to do reliably and safely. 
> 
> Any suggestions from PerlUnitLand?  I'd welcome either practical solutions
> to this problem, or even suggestions for another approach entirely.  My
> ulterior motive is that I think this decorator is useful enough to be made
> public, possibly even bundled with PerlUnit, but I don't want to do that
> unless it's more robust than this. 

This sounds like very interesting work which it would be great to
integrate into the main tree.  Unfortunately my knowledge of IPC is
very limited so I'm afraid I can't really be of much help.  I don't
suppose named pipes could be of any use?

Re: [Perlunit-devel] Possible bug in Test::Unit::Decorator

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

Matthias Ferber (mf...@hi...) wrote:
> Hi folks,
> 
> Is this a bug?  In the default run() implementation for
> Test::Unit::Decorator, I'm pretty sure the last line should be
> $self->basic_run($result) -- the test object doesn't have a basic_run
> method.
> 
> Usually run() will be overridden, but this broke a partial test I was
> trying.
> 
> sub run {
>     my $self = shift;
>     my ($result) = @_;
>     $self->{_fTest}->basic_run($result);
> }

Yes, I think you're right.  I've committed a fix.  Apologies for
taking so damn long!

Adam

[Perlunit-devel] 0.24 is out

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

Adam Spiers (ad...@sp...) wrote:
> I've released Test-Unit-0.23 on CPAN and sourceforge.net.  There are
> countless improvements over the last release; see the ChangeLog for
> all the gory details.

Argh ... I missed a bunch of files from the MANIFEST.  0.24 is out,
and hopefully will actually work.

-- 
## Adam Spiers ## musician & hacker ## me...@ad... ## http://tigerpig.org
$@=>$_=q^*{$Just =bless{},'$another ';"\$Perl \::$hacker,"}=sub{print$%[$.++];$
},eval join+v45.62,(q)$q ))x v54^,s.(?<=\$)\w*[\s,].f if+push@%,$&.sixmegs,eval

Re: [Perlunit-devel] Test::Unit::Error superfluous?

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

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

> [I mainly need a reply from Piers on this.]

Sorry for the delay.

> I've been investigating why PerlUnit occasionally dies in the middle
> of a run, and it turned out to be something in the set_up method of
> one of my test cases throwing an exception.  Currently
> TestCase::run_base only traps exceptions thrown from running the test
> method itself, not those thrown from running the set_up method.  It
> struck me that the framework should be just as robust in the face of
> run-time errors from calls to set_up() as to calls to test methods, so
> I set about fixing this, and it raised some issues.  The code in
> question is
>
>   sub run_bare {
>       my $self = shift;
>       debug(ref($self) . "::run_bare() called\n");
>       $self->set_up();
>       try {
>           $self->run_test();
>           1;
>       }
>       catch Error::Simple with {
>           # Something died, which throws an Error::Simple
>           Test::Unit::Error->make_from_error_simple(shift, $self)->throw;
>       }
>       finally {
>           # Only gets called if 'set_up' succeed
>           $self->tear_down;
>       };
>   }
>
> There are two things wrong with this.  The first I just described,
> which is that exceptions from set_up() are not trapped, causing the
> framework to die.  The second is that only Error::Simple exceptions
> from run_test() are trapped, but I can't think of any reason why the
> actual test shouldn't fail by throwing any kind of exception.  Given
> that the only point of Test::Unit::Error is to encapsulate
> Error::Simple exceptions thrown by the test, I'm wondering whether
> it's even needed.  We could just not bother trapping any exceptions in
> run_bare(), and change Test::Unit::Result::run_protected to treat
> *any* exceptions other than Test::Unit::Failure as an error,
> i.e. change
>
>     try {
>         &$closure();
>     }
>     catch Test::Unit::Failure with {
>         $self->add_failure($test, shift);
>     }
>     catch Test::Unit::Error with {
>         $self->add_error($test, shift);
>     };
>
> to 
>
>     try {
>         &$closure();
>     }
>     catch Test::Unit::Failure with {
>         $self->add_failure($test, shift);
>     }
>     otherwise {
>         $self->add_error($test, shift);
>     };
>
> Can anyone see anything wrong with this in principle?  Actually, I
> just spotted something, which is the exception passed to add_error()
> wouldn't be a Test::Unit::Exception any more, so it wouldn't have the
> set_object() method, which is used for determining which test caused
> the exception.  Any other problems?
>
> I think what I'll do in the absence of any other suggestions is change
> make_from_error_simple so that it encapsulates *any* exception within
> a Test::Unit::Error, not just Error::Simple exceptions.

If you wrap things in a 'try' then it *already* turns any
straightforward die (ie, where you die with a string not an object)
into an Error::Simple. Frankly, I don't like the requirement to
capture the Error Simple and turn it into a Test::Unit::Error, but I
wanted T::U::Error's behaviour of adding the appropriate
object. For other 'typed' errors we really don't know enough about
them to be able to reliably turn them into Test::Unit::Error
objects. Maybe if you introduced a Test::Unit::Error::Typed, which can
then contain the original error...

As for exceptions thrown by setup, I took the view that trapping these
was a bad thing to do as a failure in setup code can be thought of as
a rather more fundamental error than an error in the test code itself,
and such a failure should probably halt the test process. I assume
that that was Christian's original view too, because I haven't changed
it any. 

However, looking at SUnit, it looks like the testrunner will also
catch exceptions thrown by the setup phase. I wonder if there's case
for wrapping the calls to setup in a 'try' and having that catch any
errors and wrap them in a Test::Unit::SetupError exception. Not sure
if that grabs us any extra info though.

>
> In the course of investigating all this, I also noticed that in
> t/tlib/TestTest.pm, some tests (e.g. test_tear_down_setup_fails() and
> test_run_and_tear_down_fails()), throw Test::Unit::Error exceptions
> from within their inner classes' set_up() and tear_down() methods.  In
> real-life scenarios, this would never happen, so these are unrealistic
> tests.  I'm changing them to normal die() calls, but since they
> originate from revision 1.1 of lib/Test/Unit/tests/TestTest.pm by
> Christian, it'd be reassuring to hear someone else agreeing that I'm
> doing the right thing.
>
> Adam
>
> _______________________________________________________________
>
> Sponsored by:
> ThinkGeek at http://www.ThinkGeek.com/
> _______________________________________________
> Perlunit-devel mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perlunit-devel
>
>

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

[Perlunit-devel] 0.23 is out

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

I've released Test-Unit-0.23 on CPAN and sourceforge.net.  There are
countless improvements over the last release; see the ChangeLog for
all the gory details.

Please give it a good thrashing and send feedback here.

Thanks,

Adam

-- 
## Adam Spiers ## musician & hacker ## me...@ad... ## http://tigerpig.org
$@=>$_=q^*{$Just =bless{},'$another ';"\$Perl \::$hacker,"}=sub{print$%[$.++];$
},eval join+v45.62,(q)$q ))x v54^,s.(?<=\$)\w*[\s,].f if+push@%,$&.sixmegs,eval

[Perlunit-devel] Test::Unit::Error superfluous?

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

[I mainly need a reply from Piers on this.]

I've been investigating why PerlUnit occasionally dies in the middle
of a run, and it turned out to be something in the set_up method of
one of my test cases throwing an exception.  Currently
TestCase::run_base only traps exceptions thrown from running the test
method itself, not those thrown from running the set_up method.  It
struck me that the framework should be just as robust in the face of
run-time errors from calls to set_up() as to calls to test methods, so
I set about fixing this, and it raised some issues.  The code in
question is

  sub run_bare {
      my $self = shift;
      debug(ref($self) . "::run_bare() called\n");
      $self->set_up();
      try {
          $self->run_test();
          1;
      }
      catch Error::Simple with {
          # Something died, which throws an Error::Simple
          Test::Unit::Error->make_from_error_simple(shift, $self)->throw;
      }
      finally {
          # Only gets called if 'set_up' succeed
          $self->tear_down;
      };
  }

There are two things wrong with this.  The first I just described,
which is that exceptions from set_up() are not trapped, causing the
framework to die.  The second is that only Error::Simple exceptions
from run_test() are trapped, but I can't think of any reason why the
actual test shouldn't fail by throwing any kind of exception.  Given
that the only point of Test::Unit::Error is to encapsulate
Error::Simple exceptions thrown by the test, I'm wondering whether
it's even needed.  We could just not bother trapping any exceptions in
run_bare(), and change Test::Unit::Result::run_protected to treat
*any* exceptions other than Test::Unit::Failure as an error,
i.e. change

    try {
        &$closure();
    }
    catch Test::Unit::Failure with {
        $self->add_failure($test, shift);
    }
    catch Test::Unit::Error with {
        $self->add_error($test, shift);
    };

to 

    try {
        &$closure();
    }
    catch Test::Unit::Failure with {
        $self->add_failure($test, shift);
    }
    otherwise {
        $self->add_error($test, shift);
    };

Can anyone see anything wrong with this in principle?  Actually, I
just spotted something, which is the exception passed to add_error()
wouldn't be a Test::Unit::Exception any more, so it wouldn't have the
set_object() method, which is used for determining which test caused
the exception.  Any other problems?

I think what I'll do in the absence of any other suggestions is change
make_from_error_simple so that it encapsulates *any* exception within
a Test::Unit::Error, not just Error::Simple exceptions.

In the course of investigating all this, I also noticed that in
t/tlib/TestTest.pm, some tests (e.g. test_tear_down_setup_fails() and
test_run_and_tear_down_fails()), throw Test::Unit::Error exceptions
from within their inner classes' set_up() and tear_down() methods.  In
real-life scenarios, this would never happen, so these are unrealistic
tests.  I'm changing them to normal die() calls, but since they
originate from revision 1.1 of lib/Test/Unit/tests/TestTest.pm by
Christian, it'd be reassuring to hear someone else agreeing that I'm
doing the right thing.

Adam

Re: [Perlunit-devel] Maintaining Test::Unit

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

Christian Lemburg <le...@ai...> writes:

> Adam Spiers <ad...@sp...> writes:
>
>> Piers Cawley (pdc...@bo...) wrote:
>> > Adam Spiers <ad...@sp...> writes:
>> > 
>> > > Piers Cawley (pdc...@bo...) wrote:
>> > >> I'm doing a really crap job of this aren't I? And I've been pulled
>> > >> into working on about three other projects that are taking up all my
>> > >> time.
>> > >> 
>> > >> Adam, would you mind awfully taking on the mantle of official
>> > >> maintainer and maybe getting a release out?
>> > >
>> > > OK then.  I'll see if I can dump any of my existing projects on
>> > > someone else :-)  Can you transfer CPAN ownership?
>> > 
>> > As I didn't actually do a release I'm not entirely sure I ever *had*
>> > CPAN ownership. I'll go look.
>> 
>> Hmm, it looks like Christian still has it.  Christian, could you
>> transfer to me please?
>> 
>> Adam
>
>>From my pause account:
>
>                 Sorry, there are no modules registered belonging to
>                 CLEMBURG. Please note, only modules that are
>                 already registered in the module list can be edited
>                 here. If you believe, this is a bug, please contact
>                 mo...@pe....
>
> Also, please note this:
>
>         http://www.xray.mpe.mpg.de/mailing-lists/modules/2001-11/msg00268.html
>
> And the entry for Test::Unit in Test section of the Perl 5 module list
> at http://www.cpan.org/modules/00modlist.long.html#ID3_Development 
> looks like this:
>
> Test               Sdpf? Utilities for writing test scripts           SBURKE
> Test::
> ::Cmd              RdpO? Portable test infrastructure for commands    KNIGHT
> ::Harness          Suphp Executes perl-style tests                    MSCHWERN
> ::Unit             adpOp framework for XP style unit testing          PDCAWLEY
> ::Suite            cdpO? Represents a collection of Test::Cases       HENKE
> ::Case             cdpO? Represent a single test case                 HENKE
> ::Mail             bdpOp Test framework for email applications        SKUD
> ::Simple           bmpfp Basic utilities for writing tests            MSCHWERN
> ::Exception        Rdpfp Functions for testing exception-based code   ADIE
> ::More             RdpOp More functions for writing tests             MSCHWERN
> ::Litmus           bdpOo Submit test results to the litmus webtool ZLIPTON
>
>
> As it seems, this means that I can't transfer to you. Piers has
> ownership of the module now. I can't even see it in my pause account.
>
> Piers, could you please just log in to PAUSE and give the module to
> Adam? As the records show, I have given you the module long ago.

Ah. Sorry. Adam, what's your PAUSE ID?

-- 
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] Maintaining Test::Unit

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

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

> Piers Cawley (pdc...@bo...) wrote:
> > Adam Spiers <ad...@sp...> writes:
> > 
> > > Piers Cawley (pdc...@bo...) wrote:
> > >> I'm doing a really crap job of this aren't I? And I've been pulled
> > >> into working on about three other projects that are taking up all my
> > >> time.
> > >> 
> > >> Adam, would you mind awfully taking on the mantle of official
> > >> maintainer and maybe getting a release out?
> > >
> > > OK then.  I'll see if I can dump any of my existing projects on
> > > someone else :-)  Can you transfer CPAN ownership?
> > 
> > As I didn't actually do a release I'm not entirely sure I ever *had*
> > CPAN ownership. I'll go look.
> 
> Hmm, it looks like Christian still has it.  Christian, could you
> transfer to me please?
> 
> Adam

From my pause account:

                Sorry, there are no modules registered belonging to
                CLEMBURG. Please note, only modules that are
                already registered in the module list can be edited
                here. If you believe, this is a bug, please contact
                mo...@pe....

Also, please note this:

        http://www.xray.mpe.mpg.de/mailing-lists/modules/2001-11/msg00268.html

And the entry for Test::Unit in Test section of the Perl 5 module list
at http://www.cpan.org/modules/00modlist.long.html#ID3_Development 
looks like this:

Test               Sdpf? Utilities for writing test scripts           SBURKE
Test::
::Cmd              RdpO? Portable test infrastructure for commands    KNIGHT
::Harness          Suphp Executes perl-style tests                    MSCHWERN
::Unit             adpOp framework for XP style unit testing          PDCAWLEY
::Suite            cdpO? Represents a collection of Test::Cases       HENKE
::Case             cdpO? Represent a single test case                 HENKE
::Mail             bdpOp Test framework for email applications        SKUD
::Simple           bmpfp Basic utilities for writing tests            MSCHWERN
::Exception        Rdpfp Functions for testing exception-based code   ADIE
::More             RdpOp More functions for writing tests             MSCHWERN
::Litmus           bdpOo Submit test results to the litmus webtool ZLIPTON


As it seems, this means that I can't transfer to you. Piers has
ownership of the module now. I can't even see it in my pause account.

Piers, could you please just log in to PAUSE and give the module to
Adam? As the records show, I have given you the module long ago.

-- 
Christian Lemburg, <le...@ai...>, http://www.clemburg.com/

 Twenty Percent of Zero is Better than Nothing.
 		-- Walt Kelly

Re: [Perlunit-devel] Maintaining Test::Unit

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

Piers Cawley (pdc...@bo...) wrote:
> Adam Spiers <ad...@sp...> writes:
> 
> > Piers Cawley (pdc...@bo...) wrote:
> >> I'm doing a really crap job of this aren't I? And I've been pulled
> >> into working on about three other projects that are taking up all my
> >> time.
> >> 
> >> Adam, would you mind awfully taking on the mantle of official
> >> maintainer and maybe getting a release out?
> >
> > OK then.  I'll see if I can dump any of my existing projects on
> > someone else :-)  Can you transfer CPAN ownership?
> 
> As I didn't actually do a release I'm not entirely sure I ever *had*
> CPAN ownership. I'll go look.

Hmm, it looks like Christian still has it.  Christian, could you
transfer to me please?

Adam