* Michael G Schwern <[EMAIL PROTECTED]> [2007-12-05 15:00]: > I'm going to keep drilling through the BS until I either hit > bottom or punch through.
Yeah, we’re all spouting bullshit. Gee, some tone you’re setting. > About all that's different when the plan is at the end is the > TAP reader doesn't know how many tests are coming until the end > of the test. Then it can't display the expected number of tests > while the test is running. Not only can’t it do anything display-wise, but the harness also can’t do anything else that requires knowing the projected plan up front. It can’t abort the test as soon as the first extra test runs. If the test dies, the harness doesn’t know how many tests were pending. A system whose job is to continuously run lots of tests in parallel can’t do nearly as much useful asynchronous reporting. > Unfortunate, but hardly a showstopper. Whether or not it’s a showstopper is for the harness author to judge and not for you. It’s not hard to imagine cases where better streamability is important, even if they’re not garden- variety `./Build test` scenarios. We’re championing TAP as a solution for a wide variety of scenarios, right? But streamability isn’t important in that most common use case, so it probably shouldn’t be the default, which is why I opined that maybe Test::More should be strict on request but not by default. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
