Ovid wrote: > And here's the answer: > > I'll add a feature to TAPx::Parser which will allow one to choose whether or > not 'ok # TODO' passes.
Please don't. 1) It breaks TAP. TODO and SKIP tests pass. They've always passed. There's no good reason to change this. Breaking protocols is bad, mkay. Offering an option for the user to break the protocol is also bad especially when there's plenty of ways they can accomplish this themselves. (see #3) 2) It does not solve the proposed problem. Your worry is that someone will write a TAP displayer which does not trumpet TODOs passing and the user will not see them and it will cause all sorts of doom. If the display author gets this wrong without an option to make TODO tests fail, they obviously haven't considered the case of passing TODO tests. Why would they suddenly notice a feature to turn passing TODO tests into failures? This is a social problem. Fix it with education and documentation. Adding another feature the display author is no more likely to see than the existing ones doesn't fix things. 3) There's already plenty of ways for a displayer to shoving passing TODO tests into the user's face. They can make it blink. They can turn it red. They can phone the police. These all call attention to the TODO successes without breaking TAP. The displayer can even turn it into a failure if they really want to. Its a trivial bit of code and TAPx::Parser doesn't need to provide the carefully knotted rope. 4) This is a decision for the displayer, not the parser. By putting this decision at the parser level you are limiting the flexibility of the displayers. If a displayer is handed a parser object which has already decided its policy towards TODO tests it cannot then make the choice to display. Test::Harness mixed up parsing with displaying and we can see where that's got us.
