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
Or is it a BUG?"
"Let's call it an accidental feature. :-)"
--Larry Wall in <6909@jpl-devvax.JPL.NASA.GOV>
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Perhaps you've chosen a bad example... (Score:1)
It seems to me that the example you give is ultimately a poor test. You’re relying upon an implicit feature of the testing interface to test for explicit behaviors of your code. As a person new to your project how I am supposed to know that
list()is only ever supposed to return two elements? Sure the tests fail but how do I know that the tests were correct in the first place?By making an explicit test for the explicit behavior, I can communicate to someone else that I’m expecting
list()to only ever return two elements, and that doing differently is actually changing known behavior.Say what you will bout
done_testing, you may like it or you may not (personally I hate having to update my test count, but I was willing to useno_plan). Relying upon implicit behavior of your environment to provide you with explicit behavior of the code your writing is a bad practice.Reply to This
Re: (Score:2)
I agree with your assessment of no_plan, at least when you used it you were explicitly saying there was no plan...
Re: (Score:1)
--fREW
http://blog.afoolishmanifesto.com
Re: (Score:1)
done_testingfor future code.Re: (Score:2)
no_plan won't detect early termination, but Test::Harness will note the non-zero exit status on a die.
Re: (Score:1)
It is more common than I'd like to see END and DESTROY blocks do something that clears the exit status of a Perl program on its way out the door.
In fact it is common enough that I'd prefer not to rely on it to detect abnormal ending of a test suite. Particularly since many test suites like to do cleanup when they are done.