Ovid wrote:
> I'll go fix that diagnostic thing now. Unfortunately, I think I'll
> have to violate encapsulation :(
If you know how to fix it let me know, because other than enumerating each
testing module you might use and lex-wrapping all the functions they export,
I'm not sure how to do it. Test::Builder could cheat and register each module
as they load Test::Builder, but that relies on their using Test::Builder and
not requiring it. Or builder() or new() could do the registration, but
there's no guarantee that they'll be called in the right package... however,
it is very likely.
One possibility involves taking advantage of $Level, so at least Test::Builder
knows which is the test function the user called, and then, somehow, inserting
the code necessary to cause failure when that function exits. I don't know
how you insert code to run when a function that's already being executed exits.
This is why I altered the recommended calling conventions for Test::Builder to
call ->builder at the beginning of each function rather than just use one
global. Then at least I can use the builder object's DESTROY method to
indicate the end of a test to trigger this stuff.
There is, of course, a way to eliminate the problem at the source. Since the
issue is the spewing test output and then having to scroll up to find the
original point of failure, perhaps the solution is not to truncate the output
but to use something better than just raw terminal output. If only there was
something that could... I don't know... read the TAP and error messages and
produce a nicer output. Some sort of TAP parser... :P
--
<Schwern> What we learned was if you get confused, grab someone and swing
them around a few times
-- Life's lessons from square dancing
