Piers Cawley ([EMAIL PROTECTED]) wrote:
> Matthew Astley <[EMAIL PROTECTED]> writes:
> > What I'm after is a way to get hold of "debug output from that module"
> > quickly, without going round uncommenting stuff or changing constants.
> > I can see there could be some use in (by default) hiding debug output
> > from any test that passes, but this still doesn't allow control of the
> > fountain of goop that should erupt from the internals of the test
> > system.
Exactly. I think we're muddling two different sets of debugging into
one here. On one hand, we the PerlUnit developers want a handy
debugging system for when we're frobbing around inside the framework.
On the other hand, PerlUnit users, who have installed the modules off
CPAN (and who hence will have them read-only somewhere under
/usr/lib/perl5) will want to be able to add debugging to their own
tests, but in theory should never have to enable the former set of
debugging, because PerlUnit should Just Work for them. If it doesn't,
and they want to get their hands dirty, fine, but then they become
PerlUnit developers like us, and can expect to have to edit the source
to Test::Unit::*.
How about we keep these two sets separate? (I'm sure there's scope
for reusing code between them, however.)
> > I think last time this subject came up we were also talking about
> > keeping state somewhere per test case/suite .. ?
If you're thinking of when I brought it up, I suggested ...
> Eww... If you're going to keep state like that, keep it per run and
> stick it in the Listener methinks.
... yep, adding state to the runner. I have a patch for this, in fact.
Or at least, I will, once I've resolved all remaining conflicts ...
> $self->debug(internal => $msg,
> user => $other_message)
I'm not convinced by this, for reasons listed above.
_______________________________________________
Perlunit-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/perlunit-devel
