On Fri, 6 Feb 2004 13:34:01 -0800, Michael G Schwern wrote:
>
> Test::Harness parses 'ok' and 'not ok' and 'Bail out'... Test::*
> modules produce the output Test::Harness parses. So your extra logic
> to parse "depends on" would go into your Test::Harness extension, but
> the depends_on() function to produce it would go into a seperate
> Test::* module.
I agree, but I still believe it would be good if Test::Harness
laid out syntax rules for extensions. Defining a standard
for how test <-> harness communication is done will avoid
accidental parsing of test output.
Let me summarize what I've done as an example.
On the test side of things each of my test files now have one
additional line. For example:
use Test::More tests => N;
use Test::Depends qw(:auto);
That :auto import ensures that %INC dependencies are inserted
into the test output stream automatically when the test exits.
Explicit calls to depends_on(...) are allowed too, but not
required.
On the harness end of things I used Test::Harness::Straps to
create Test::Continuous::reruntests(). The callback function
knows what the Test::Depends code will insert into the test
output stream and parses it appropriately.
The hazard I see is the messages generated by T::Depends and
parsed by T::Continuous are completely up to me. A test writer
might inadvertently generate their own diagnostic messages that
T::Continuous mistakenly parses.
With a nod towards SMTP header extensions (e.g.
"X-Mail-Software: ...", "X-URL: ...", or "X-Server: ...") I'll
suggest "# Test-X-FOO: ..." as a base syntax.
The T::H documentation sections "The test script output" or
"Anything else" could state that comments starting with
"Test-X-\w+:" are used for test extensions. Then my T::Depends
extension would use the pattern /^# Test-X-Depends: (.*)/
safely.
Comments?
Scott
