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. My point is that mixing
Test::Builder outputs is bad juju:
ok 1
ok 2
ok
ok 3
ok 1
ok 2
ok
ok 4
Maybe "stuck with" isn't the right phrase, but the conservative in me says
"test numbers will be around for a while." Plus, I *like* them as a final
sanity check.
> 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?
> 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.)
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.
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...
-- c
