[Perlunit-devel] Greetings

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

Hi folks -- you've all probably seen Christian's and Piers's responses to
my query on the other newsgroup, so I won't repeat all the background
here.  (I thought I remembered seeing something on sourceforge about this
list being the totally dead one and the other one only mostly dead, but
apparently my memory was playing tricks on me.)  Christian and Piers,
thanks to both of you for the fast and helpful answers.  It looks like the
interface changes in progress are mostly things a little searching and
replacing could take care of, so I'm going to press onward with what I'm
doing.

At any rate, I'm really liking PerlUnit in its current form and I'd like
to be of assistance however I can.  For the moment that's probably limited
to enthusiastic feedback and questions, but perhaps in the future I'll
have time to be more constructive if you're looking for more help.

I do have these bits of feedback and suggestions, nothing major.  Bear in
mind that I don't know what you're working on now, although I've been
browsing the CVS tree and I see that you've anticipated at least some of
these things...

1) There's no indication yet (that I noticed) of which methods in an
object are intended to be the public interface and which are for internal
use only.  This is important for what I'm working on, because (for reasons
that I won't go into here) I need to invoke TestSuite::do_run() directly
from a script instead of invoking a TestRunner.  If that method isn't
meant to be public, then I'll need to find a workaround, which may lead to
a feature request.  [Actually I think I've just figured out how I can
avoid using this method directly, but still...]

2) I was going to ask if there were any plans for specialized assert() 
methods, like assert_equals, but I see that this is already the direction
you're moving in, which is great.  In particular, I'd like to put in a
plug for assert_matches(regex, string) and assert_not_matches (or
something).  The scheme for using assert() with a regex as the first
parameter is cool, but to test a non-match you have to use a hack, and in
either case you're limited to the default failure message, which for a
regex is likely to be unhelpful.

---Whooops, I see that the message parameter has been added more recently. 
That's terrific.  It would still be nice to have a not-matches assertion,
though, to avoid the (?!) hack.  I'm doing this kind of test, and I
resorted to the scalar(x=~y) syntax instead because it seemed less ugly. 
(I've just discovered the neat trick in Assert.pm for reusing coderefs as
assertions.  That's cool.)

3) Without turning Perl autoflushing on, you can't see the tests
proceeding in a text-based test.  It would be cool if the suite, or
whichever class does the output, could ensure that $| is nonzero so the
dots get displayed as soon as their written.  (Maybe it could even restore
the original value.)  I'm doing that explicitly in the script I've
written. 

It also occurred to me that a "nice-to-have" would be a verbose option
where it displays the name of each test and the TestCase class as it
progresses.  I don't think JUnit has that either, but I found myself
wanting it yesterday.  (Ooh, I see you've made the debug setting global.
Very nice.)

The SourceForge feature request tracker doesn't seem to be getting much
use but I could put these in there if that would help.  Again, you guys
are doing really good work here.  I was very surprised, incidentally, that
a Perl port wasn't finished long ago, but go figure.

Gotta get back to my real job now.

-- Matthias Ferber
   mf...@hi...