chromatic wrote:
These are *generated* files. Are you in the practice of checking in generated
files -- and not just files generated deliberately as part of a multi-stage
compilation or deployment process, but files generated as a temporary
byproduct of asking the question "Does the as it exists now work correctly
right now?"
Even in the few cases where you need to shuttle TAP documents back and forth,
the plan is to include version information in the document, correct? Isn't
the point of including a version so that TAP consumers will be able to
consume the document correctly?
We are trying to avoid having a lock step upgrade process between the TAP
producer and consumer. There are many more producers than consumers, and the
producer doesn't always know what the consumer can handle. So we're trying to
provide a backwards compatibility path when possible.
It also means we can provide nice subsets of TAP that remain the same through
upgrades allowing users to transition up to new versions slowly.
Finally, since old TAP parsers don't know anything about the version headers
and ignore all non-TAP lines we're trying to avoid the case where new TAP
which should fail is mistakenly allowed to pass in an old parser. That is the
worst possible scenario. Even having new TAP which should pass instead fail
when run through an old parser is much more desirable.
Really? Schwern threw in the towel and admitted that Test::Builder
isn't architecturally able to suit our needs. If Schwern admits this,
I suspect that it's not fair to attack organizations for not being able
to do in an afternoon what Schwern admits can't be effectively done.
Both of our arguments presume the existence of an API for adding TAP
diagnostics to a TAP stream. If the API is so difficult to use that
organizations never emit any TAP diagnostics beyond those which Test::Builder
emit by default, there's no problem. This is a red herring.
If those organizations are able to emit custom TAP diagnostics, they should be
able to change the code which calls this API. I recommend suggesting that
people and organizations remove duplication from their test suites by
factoring out identical code and testing patterns into testing modules --
just as we've done for several years now.
Allow me to clarify. It's an architectural oversight in the Test::Builder
design that makes it difficult to output the diagnostics, not the diagnostics
themselves.
Simply put, Test::Builder doesn't know when a test is done, the old reason why
it can't provide "die on fail" behaviors. The YAML must be built up and
merged from Test::Builder's default diagnostics (file, line, etc...) and the
user test function diagnostics (have, want, etc...). Since Test::Builder
doesn't know when the user test function has ended it doesn't know when it
should dump out the diagnostics. Since I want user supplied diagnostics to be
able to override the Test::Builder supplied ones I can't just spit them out as
I get them.
There are hacks, TB could dump out the previous test's diagnostics just before
it starts the next test, but that's unpleasant. Also note that a simpler,
flat system, and all the other TAP producers at this point have nothing like
Test::Builder, has none of these problems. Future Test::Builder style TAP
producers will be written with this issue in mind.
So don't panic, it's just a combination of my being fastidious and a
Test::Builder design quirk that needs to be solved for about 5 other reasons.
--
125. Two drink limit does not mean two kinds of drinks.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/
