chromatic wrote:
On Tue, 2005-03-08 at 14:54 -0500, David Golden wrote:Let me say it a different way. Right now, Test::Builder and Test::Harness (et al.) are tightly coupled. It would be nice to break or at least reduce that coupling. Stuff deep in Test::Builder assumes that the output is TAP. For example, consider the way that ok() doesn't just store a result in the results array but goes to all the trouble to print it out in TAP format with both _print() and _print_diag(), too. (Presumably, that's what's being refactored into TestOutput?)
Also, in thinking through the reorg of Test::Builder, it would be great if the notion of "success" or "failure" could be isolated from any particular form of output. That would mean that someone could use Test::Builder::TAP (for TAP style output) or Test::Builder::HTML for custom output purposes. (As opposed to the current approach of using Test::Builder to speak TAP to Test::Harness to gather results to either print or do other things with.)
Hm, this is less convincing to me. Still, you can do something different with Test::Builder::TestOutput if you want.
One of the side effects of this is that diagnostic messages from the ok() blend in with any user generated diagnostics and that's the only way to get at them. Details() doesn't actually give details about why tests failed, either, which would be nice for anything that is extracting details for some custom purpose. It would seem to make sense to put that in the "reason" slot of the details, except that most derived tests are written to use "ok($expr) or diag($message)". That's equivalent to "(record details and print stuff out) + (print other stuff out)". It would be nice if there were better symmetry so that something like is() could stick its "got X, expected Y" message in "reason" field of the details array if it fails.
David
