On Mon, 11 Nov 2002, Michael G Schwern wrote:
> chronomatic wrote:
> > My point is that mixing. Test::Builder outputs is bad juju:
>
> Test::Builder->new would remain as a singleton. We'd just provide an
> alternate constructor to provide a second object if someone really wants it.
You know, that would at the very least tidy up Test::Builder::Tester
somewhat. It's currently just a bit of a hack...(sssh, I didn't really
say that)
> > > Maybe I should check my hospital receipt, make sure all they took
> > > out was my appendix. What's this scar on the back of my head...?
> >
> > And why are you beeping?
>
> I get Comedy Central if I stand on my head.
See, I told you not to take the tin foil hat off, but no-one listens...
> > > With two T::B objects, we could beat on one object while leaving
> > > another in a normal state to perform the tests.
One day (maybe not this rewrite, maybe not the next) I'd like to see you
be able to write layers of tests. That is to say that you have some kind
of Test::Harness like system running actually inside a Test::Builder test
that runs another set of tests and returns "ok" or "not ok" if all *its*
tests returned "ok" or not. And then you could have subtests within that,
down to an arbitary level of abstraction. Does this make sense?
Actually probably not...but I can *handwave* too ;-)
I think we might have to lose the singleton if anything like that was ever
to work.
> > I suppose we could also log only certain kinds of tests, too. That
> > might make some of my fiendish plans easier. (Log only can_ok(), in
> > this T::B object.)
Yes, or with the above mentioned crack fueled scheme you could say only
log the first level, or the second level... you get the idea.
> Hmmm. All those *output calls are really irritating. I think I'll change
> it to something like this instead:
>
> package Test::Builder::Log::like;
>
> my %outputs = map { ($_ => 'some_output.log') } qw(test failure todo);
> sub like {
> my($self) = shift;
>
> # Add outputs() to combine all three *output methods
> # together. Also, have it return the former set of
> # filehandles.
> my %old_fhs = $self->outputs(%outputs);
>
> local $Test::Builder::Level = $Test::Builder::Level + 1;
> my $ret = $self->SUPER::like(@_);
>
> $self->outputs(%old_fhs);
>
> return $ret;
> }
Not that I'm one to break OO boundaries, but by allowing of breaking the
OO boundaries just a little bit by skipping the accessors you could just
do this, which means you are less likey to shoot yourself in the foot with
forgeting to reset the outputs back again.
package Test::Builder::Log::like;
my %outputs = map { ($_ => 'some_output.log') } qw(test failure todo);
sub like {
my ($self) = shift;
local $self->{outputs} = \%outputs;
local $Test::Builder::Level = $Test::Builder::Level + 1;
return $self->SUPER::like(@_)
}
Level should probably be moved to $self->{level} in that example too.
Oooh, I don't even want to think about the problems of backwards
compatability with that right now...
> > Maybe we're too coarsely grained on the singletonness. It's only the
> > test counters and outputs that really need to be single, right?
In the above crazy scientist scheme of havinging a stack of Test::Builder
objects, then not even the test numbers have singletonness, as each level
of the stack has it's own testing numbers (which are never exposed to the
level above).
> I can't think of why you'd want two T::B objects which are only partially
> sharing state.
Agreed.
> > > The real reason why I put all the data into lexicals rather than a hash is
> > > because its easier to type $Have_Plan than $self->{Have_Plan}.
http://magnonel.guild.net/~schwern/talks/Refactoring/slides/slide015.html
;-)
Mark.
--
s'' Mark Fowler London.pm Bath.pm
http://www.twoshortplanks.com/ [EMAIL PROTECTED]
';use Term'Cap;$t=Tgetent Term'Cap{};print$t->Tputs(cl);for$w(split/ +/
){for(0..30){$|=print$t->Tgoto(cm,$_,$y)." $w";select$k,$k,$k,.03}$y+=2}
