Gabor Szabo wrote:
> Going along the path of testing the examples in my distribution,
> I think it could be generalized. What do you think about this?
I think putting the expected output into files fractures the test so that its
not obvious from just looking at the test what's going on. You have to jump
around.
It also might be handy to unify the input/output format so its more like a
conversation. Compare splitting things up:
stdout => <<'END',
Please enter an email address:
Please enter an email address:
Mailing spam now...
END
stdin => <<'END',
schwern
[EMAIL PROTECTED]
END
stderr => <<'END',
"schwern" is not a valid email address
END
With unifying them:
conversation => <<'END'
OUT: Please enter an email address:
IN : schwern
ERR: "schwern" is not a valid email address
OUT: Please enter an email address:
IN : [EMAIL PROTECTED]
OUT: Mailing spam now...
END
Which would you rather write and maintain?
Also, I'm not sure test_all_examples() is all that useful as it allows you to
test each example only once. Presumably you're going to want to try a few
different inputs.
Finally, what does this module have to really do with examples? It just runs
programs. Is there already a module to test running scripts? If not, perhaps
this can be it but don't call it Test::Example, call it Test::Script.
> chdir 'myexamples';
> system("$h{script} @{ $h{argv} } < $h{stdin} > temp_out 2> temp_err");
Very, very, very un-cross platform. Don't even describe it this way in the
docs, non-Unix gurus will have no idea what you're talking about.
Instead tie/reopen STDOUT, STDIN and STDERR.
