Shlomi Fish wrote: > On Monday 24 April 2006 01:46, Michael Peters wrote: >> Shlomi Fish wrote: >>> On Sunday 23 April 2006 22:35, chromatic wrote: >>>> On Sunday 23 April 2006 12:05, Shlomi Fish wrote: >>>>> This debate demonstrates why a plugin system is necessary for a test >>>>> harness. >>>> No, it demonstrates why a well-defined test output protocol is useful. >>> I agree that a well-defined test output protocol is useful. However, are >>> you implying that assuming we have that, one can write several different >>> test harnesses to process such test outputs? (I'm just guessing.) >>> >>> Wouldn't that imply duplicate code, duplicate functionality and/or >>> duplicate effort? Shouldn't we try to avoid that by making sure that we >>> have one *good* test harness codebase that can be customised using >>> plug-ins, and extensions? >> How about a good TAP parser module that does nothing but parse TAP. Then >> it could be used in all kinds of test harness permutations. > > Am I missing something or isn't that what > Test::Harness:Straps/Test::Run::Straps are for? If not, I suppose I can > extract a class out of Test::Run::Straps that will provide a reusable TAP > parser.
It's close, but it's still a test harness first and foremost (even though it's pretty easy to subclass). If you extract out the TAP parsing portion into a separate module I think we'd be in good shape. It can be extremely useful to have the TAP parsing and test running separated out. Not only would this make it easier to have a harness look for something other than TAP (maybe some other protocol from some other language) but it also means I can parse test runs after they've been run on a completely different machine even. -- Michael Peters Developer Plus Three, LP
