On Mon, Nov 11, 2002 at 02:51:00PM -0800, chromatic wrote:
> On Monday 11 November 2002 14:40, Michael G Schwern wrote:
>
> > > We *could* add a method called really_create_a_new_builder() that doesn't
> > > have the singleton properties, but what problem does that solve? As long
> > > as we're stuck with test numbers, we have to try not to confuse
> > > Test::Harness.
>
> > Little known fact: test numbers are optional.
>
> With the mandatory Test::Harness upgrade, yes.
No, they've always been optional. Don't try to pin this one on me! :)
$ cat ~/tmp/nonums.t
#!/usr/bin/perl -w
print <<'TEST';
1..3
ok
ok
ok
TEST
$ perl5.4.0 -MTest::Harness -e 'runtests @ARGV' nonums.t
nonums..............ok
All tests successful.
Files=1, Tests=3, 0 secs ( 0.00 cusr 0.02 csys = 0.02 cpu)
> 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.
> > I know people have grumbled before about there being no way around the
> > singleton property, I just can't remember why. I'm doing that a lot
> > lately. 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.
> > Ok, here's one from me.
> >
> > It would make Test::Builder easier to test itself for one. There's lots of
> > T::B tests which deliberately throw it off into some bizarre state or cause
> > lots of failures. These results must be pipped off somewhere and analyzed
> > seperately. For those tests, we're back to using a hand-rolled ok()
> > function.
> >
> > With two T::B objects, we could beat on one object while leaving another in
> > a normal state to perform the tests.
>
> Simplifying the tests there is a *good* reason. They scare me.
>
> 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.)
Hmmm... can_ok() isn't a T::B method. Ooops.
In theory you could write a T::B subclass which calls each method in a
wrapper to change the output. Something like:
package Test::Builder::Log::like;
sub like {
my($self) = shift;
my $old_output_fh = $self->output();
my $old_fail_fh = $self->failure_output();
my $old_todo_fh = $self->todo_output();
$self->output('some_output.log');
$self->failure_output('some_output.log');
$self->todo_ouptut('some_output.log');
local $Test::Builder::Level = $Test::Builder::Level + 1;
my $ret = $self->SUPER::like(@_);
$self->output($old_output_fh);
$self->failure_output($old_fail_fh);
$self->todo_output($old_todo_fh);
return $ret;
}
Something like that, obviously made more generic <hand wave>.
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;
}
> Maybe we're too coarsely grained on the singletonness. It's only the test
> counters and outputs that really need to be single, right? We could make
> Test::Builder::Counter and Test::Builder::Output as singletons and let
> Test::Builder use those by default. For the tests, we could mock them or
> override them, or whatever we find necessary.
I think its more complicated than that. Depends on how its being used.
Right now my use would be to effectively have two independent tests running
in parallel in the same process. One test being the beating which is
testing Test::Builder and the results are trapped, the other test doing the
testing of the first.
In this case, you don't even want the counter and output as singletons. You
want complete seperation. Two tests running in parallel without any
interference.
I can't think of why you'd want two T::B objects which are only partially
sharing state.
> Serious suggestion.
>
> > 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}.
>
> Hmm, perhaps a source filter that allows:
>
> .$Have_Plan
>
> It's only one character longer...
Is it .$Have_Plan this week? I thought it was $.Have_Plan.
--
Michael G. Schwern <[EMAIL PROTECTED]> http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
Good tidings, my native American Indian friend! America will soon again
be yours! Please accept 5th Avenue as an initial return!
