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.