chromatic wrote:
> (I know; it's not exactly what you were asking. I just wanted to get that in
> a public mailing list so I could call that the "Star Trek: Generations"
> fallacy. You steal a spaceship, which flies through space, to fly through
> space to a planet, flying through space, where a temporal anomaly, which also
> flies through space, deflected by a supernova, which you flew through space
> in your spaceship which flies through space, passes close enough to the
> planet, because both of them fly through space, that you can jump off a
> bridge into it.)
Its all tachyons, man.
> I'm sympathetic to the argument that your test file is going to be ugly when
> the code you're testing is ugly, but it seems to me that containing that
> ugliness within the specific test file until you can refactor the test file
> is much better than bolting another ad-hoc feature onto a testing system
> which already makes way to many underspecified assumptions and would be
> fairly difficult to replace with something nicer, someday.
I agree. There's a simple, existing solution to this problem and its not one
we want to encourage anyway. The situation would be different if the same
people didn't control the tests and the code being tested, and thus required
some sort of coordination, but they do control both sides.
And it won't work anyway.
Having $ENV{RUNNING_TESTS} = 1 should presumably indicate that we're running in
a testing environment. Ok, but how does Test::Builder know that? Answer: it
doesn't. Loading Test::Builder does not imply tests are being run. An example
of this, off the top of my head, is Jifty which always loads Test::Builder (for
hacky reasons, I admit). I'm sure with a little thought one could find more,
but even if not I do not want to the loading of Test::Builder to imply we're
running in a test environment. It limits Test::Builder.
Ok, what about setting it when a plan is initiated? Surely that means tests
are being run? Consider Test::AtRuntime, a Test::Builder derived module
designed to embed tests in the code to be executed during normal operations to
help catch and diagnose errors. Basically an extension of the run-time
assert() concept. Test::Builder is loaded. There's a plan. Test functions
are being executed. But the system is operating normally. A similar problem
would occur if I ever got around to moving Carp::Assert over to using
Test::Builder for its guts.
This might seem like nit-picking for a corner case, but Test::Builder is
designed to be generic. The more automatic "convenience" features which get
built into it the less generic it is. The less generic it is the less neato
testing modules can be spawned from it. So I push back at them and encourage
them to be built in one level up on top of Test::Builder.
