Stories
Slash Boxes
Comments
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • The benefit of done_testing() is that you can be certain that "we got this far and ran this line of code."

    But there's nothing like that in your subtest sub {}, so you can't be sure that there wasn't some a goto(), exit(), or return() which silently caused a bunch of tests to be skipped.

    Similarly, END {done_testing()} does nothing that wasn't already accomplished by 'no_plan'. Calling done_testing() at the lexical end of your file is an assertion about control flow.

    Thus, an implicit done_testing() on a 'wit

    • Good points out the normal use of done_testing(). That was silly of me :)

      As for the implicit version in subtests, you won't get that with "no_plan", either, something many people are going to use anyway, if they use tests at all (well, the "exit" isn't true, but your comments about "goto" and "return" are correct). Now I think you've made the clearest arguments about this, but your arguments apply to "no_plan", also. Would you argue we not have that? We do and it won't go away.

      One argument in favor of having a number of tests asserted was that we it protects us from incorrect iteration counts. Many people who argued for disposing of plans altogether argued that you should just assert the number of iterations and not need a plan. This brings us full circle back to the whole "plan tests => $num" argument versus "no_plan". In this case, an implicit done_testing() is no worse than an explicit "no_plan" (and arguably better because it makes things easier to read), but we're going to see plenty of subtests with that because that's how people write tests. Is there a better way?

      Note that you have similar issues to these in many xUnit frameworks but I don't hear people screaming about those :)