It will catch any problem that causes the test script to not run to completion.

Most of those are already caught. So the protection that it adds is against any problem that causes the test script to not run to completion but not report a(n uncommented) failure and also exit with a 0 status result (I presume -- I haven't personally checked resently that Perl tests notice such problems).

The types of errors that I think are more common than those are programming errors in the test script that cause tests to be run too few or too many times. For example, something that causes a test to be skipped or that causes a problematic test that isn't supposed to be run with this release to be run anyway.

When I think of loops I've written in test scripts, the cases I come up with usually have the number of iterations determined by some data in the module and there are usually more than one loop over the same items. So I don't find that testing a count near each of the loops to be putting the count near to the data that determines it. But I'm glad that your technique works for you.

Stepping further back, the "need" for the plan count is a symptom that the test output is too regular and boring. I'd rather have the test script output much more interesting values that are compared against the "known good" output that is included with the test script (in a separate file). All of the work to write modules to auto increment test numbers and to associate test names with test numbers, etc. is to overcome this flaw in the design of traditional Perl test scripts, IMO.

I'd rather define a simple output format similar to here-docs where a line of output declares a test's name and includes one of 1) a notice that the test was skipped, 2) the simple results of the test (such as a count or fairly short string), or 3) the terminator that marks the end of the output for this specific test (when on a line by itself). Then the harness could still report how many tests failed or were skipped, but the person investigating the test failure would be left with a text file containing the expected output and another containing the actual output, which I think would usually be a ton more helpful than just getting a list of integers.

Then the hokey "plan" becomes pretty useless. (:

- tye        

In reply to Re^7: How can I write Test::Finished? ("ok" isn't) by tye
in thread How can I write Test::Finished? by samtregar

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.