Re: [Perlunit-devel] Greetings

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

Piers Cawley (pdc...@bo...) wrote:
> Matthias Ferber <mf...@hi...> writes:
> > 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.

Yeah, this is bad.  Eventually all public methods should be documented
by accompanying pod, I guess.

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

Agreed.  The fact that PerlUnit is aimed at developers is inevitably
going to blur the lines between private/public.

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

Sounds good.  I might hack that up now ...

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

Committed ...

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

Yep.  Can you give us an example of the output you'd like to see?  (Or
a patch ;-)

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

I better summarise the status quo w.r.t. debugging just in case my
recent changes have confused anyone.  First, there is no longer a
DEBUG constant anywhere; it has been replaced with a more unified
approach in Test::Unit::Debug.  This means debugging no longer gets
optimised out by the compile phase, but it's extremely unlikely that
this will cause anything more than a negligible performance hit.
Test::Unit::Debug is another case of "semi-privacy"; you can use it if
you want, but it's only really there for people messing around with
the framework.  On the other hand, if you want to debug your own test
cases, you can now do 

  sub test_case {
    my $self = shift;
    ...
    $self->print('some debugging\n');
    ...
  }

and the debugging will only appear if the test case fails.  This is
currently only supported by TestRunner.pm.  Maybe we should think of
a better name than print().

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

Worth chucking these ideas in doc/TODO, even if they are a bit vague
at the moment?