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

[Adam S. <as...@gu...>]

Adam Monsen <am...@co...> writes:
> I'm liking Test::Unit. I've never used JUnit, but now I'll never have to!
> (or at least I'll learn JUnit faster whenever I do start coding in Java)
> 
> I've been using Test::Unit::TestCase with excellent results.

Great :-)

> Test::Unit::TestRunner is quite handy. I use the following script to run
> tests...
> 
>   #!/usr/bin/perl -w
>   use Test::Unit::TestRunner;
>   use strict;
> 
>   chomp(my $script = `basename $0`);
>   die "Usage: $script <modules>\n" unless @ARGV;
>   for (@ARGV) {
>     s/\.pm//g;
>     my $testrunner = Test::Unit::TestRunner->new();
>     $testrunner->start($_);
>     print "\n";  # make it pretty
>   }
> 
> I use basename becuase I think it should recognize filenames as well as
> modules.

You could avoid the fork() to and dependency on an external program:

    use FindBin qw($Script);
    die "Usage: $Script <modules>\n" unless @ARGV;

> The added newline is because TestRunner doesn't print one after
> printing out timing information.

Please try checking out the CVS tree and using that.  There have been
many improvements made to it since the last tarball release, including
ones fixing newline issues such as this.

> Here are a few issues/requests/whatever I have with Test::Unit...
> 1. Is there any way to order tests?

Yes, in the CVS version.  See the NOTES section of the
Test::Unit::TestCase man page.  Piers: any objection to making
list_tests sort lexically?  I think it's a very convenient default,
and it won't cost anything significant in terms of performance.  BTW,
personally I wouldn't call having to use package lexicals/globals for
persistent data a bug.  Seems a pretty nice, logical way of doing it
to me.

> 2. Is there any way to plan for X number of tests like with Test.pm?

This is already taken care of by the Test::Unit::HarnessUnit runner,
which outputs in the same format that Test::Harness expects.  However,
the "native" PerlUnit runner Test::Unit::TestRunner doesn't bother
with planning tests.

> 3. Listing the test names would be cool, this could be a "verbose" option or
> something. I usually do something like this:
>   sub test_email_results {
>     my $self = shift;
>     warn +(caller 0)[3]."\n";
>     # Test Code Here
>   }

As of yesterday, CVS contains a unified debugging mechanism, so you
can turn on debugging in the packages of your choosing from your
runner.  See TestRunner.pl for an example of this.

> 4. when an assert fails, it would be nice to know on what line the failure
> occurred

This is supposed to happen in CVS now, although I think it's broken
for the assertion methods created in Assert.pm via %assert_subs.
Something to do with messing around with $Error::Depth, but I don't
fully understand how this is supposed to work yet.  Piers, any ideas?
We need a test for this too.  The problem is listed in doc/TODO.

> 5. I can't get quell_backtrace() to work (ie: a test sub dies, and a
> backtrace is given even if $self->quell_backtrace() is called within the
> same test sub). Where should I put a call to this method to get it to
> actually work?

In CVS, quell_backtrace() is no more; it has ceased to be, kicked the
bucket, snuffed it.  It is an ex-method ...

> I would like to contribute to this package if you want/need any help.

Yes please!  Like Christian said, the biggest help to us right now is
feedback on how the CVS tree works for you.

> It's
> interesting, and I'm excited to make good use of it. I have a heightened
> sense of awareness about software testing after reading about the Therac-25
> accidents <http://courses.cs.vt.edu/~cs3604/lib/Therac_25/Therac_1.html>,
> but I have much to learn about effective testing.

Let's hope our bugs don't have consequences as bad as that 8-)

Adam