NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
about I/O disciplines and I should retire to the Tassili-in-Aijer
mountains in Sahara as a camel herder :-)
-- Jarkko Hietaniemi
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Why AUTHOR_TESTING? (Score:1)
AUTOMATED_TESTING instead?
Re:Why AUTHOR_TESTING? (Score:2)
That's very much a mixed bag. On one hand, yes, you clearly would want it in those tests. On the other, it's not confidence inspiring to see a lot of test failures when you're evaluating a module. Of course, people say "yes, but you should check to see what causes those failures", but this is problematic. Many, many times I've received a failure report with absolutely no information about why something has failed. Or I get a failure report with spurious information, which is just as annoying.
If Schwern allows automated testing, not only does he have a good chance of getting bogus failure reports, he might find himself in the annoying position of getting into wasteful dialogues with some testers who aren't familiar with this issue and really, why should they be?
OK, that was all just spewing as I sorted out my thoughts. I guess what would be good is to have a special type of "no report" test. In other words, a test which can fail, sort of like a TODO, but which automated tests shouldn't report. I'm unsure of the mechanism here. Didn't someone on Perl QA mention something like this, or am I smoking crack?
Reply to This
Parent