Re: [Perlunit-devel] Greetings

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

Matthias Ferber <mf...@hi...> writes:

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

I'd consider do_run to be a 'semi' private method. You're going to
need to know about it if you're writing a Runner, but most of the time
you're not going to go near it.

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

Thanks. I did the Assert reworking and looking at it now I seem to
have overcomplicated it somewhat, but it's definitely flexible :).

How about:

$self->assert_matches(qr/.../, $value, $message) 
$self->assert_does_not_match(qr/.../, $value, $message) 

assert_matches is almost exactly like assert(qr/.../), but it fails if
it's not passed a pattern as its first argument.

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

That's something for the Runner class. I would be nice though.

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

Again, that's something to hang off the runner, and it definitely
looks possible.

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

I'm seriously considering hiding the debug variable from end users and
providing a bunch of ->debug, ->info, ->notice type methods which the
runner can display or not as it chooses and using the debug variable
solely for framework debugging stuff. One of the problems with the old
stack dump stuff for instance was that it was only really of any use
to framework developers, and it was a pig to turn off. 

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

It's sort of confusing. It's sort of finished, but it is also poorly
documented and much harder to extend than it should be. It's been
usable for a long time now, but it's been, well, ragged 'round the
edges so we need to get those tidied up before we can slap a 1.0 label
on it. 

And then the fun really begins. I want something which will make it
easty for non programmers to specify acceptance tests for instance.
And Test::Unit::Web would be nice, and something to do mock objects,
and...

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