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.

Why no plan for nested TAP? 10 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • Regardless of what you think about counting tests, I think this is a significant change of the way that Test::More works. Up until now, everything has had to be explicit, whether through "tests", "no_plan", or done_testing().

    • Why is this a bad thing?

      • Because being explicit allows you to be sure that the test hasn't stopped prematurely in ways less dramatic than crashing outright.

        • Sure, for the top level test. Any subtest without a plan or "no_plan" has done_testing() called for it. I did that to ensure that no subtest stopped prematurely in ways less dramatic than crashing outright. That being said, it won't stop someone from writing a subtest with a "return" statement prematurely terminating it, but then, "no_plan" won't stop that either. So if you want to be strict, add the plan. Otherwise, don't. Like every other form of testing in Perl, you'll probably get the results you

          • That being said, it won’t stop someone from writing a subtest with a return statement prematurely terminating it, but then, no_plan won’t stop that either.

            That’s exactly the point. If done_testing isn’t safer than no_plan, then what’s the point of done_testing?

            The idea behind done_testing is that because it is explicit, it makes a stronger assertion than any implicit assumption could be. To call done_testing implicitly is utterly redundant. It does not and cannot tell us anyth

            • Two points: if we don't allow the implicit done_testing because we think it doesn't provide us much safety, then why are we allowing no_plan? It's hypocritical to allow one and not the other, no? (Oh, I know -- backwards compatability). Frankly, I find when I write subtests, I put many of them in a file and I don't want to keeps adding boilerplate over and over and I'd like to find a way to avoid that.

              I have been, over the years, an explicit advocate of the plan and I think it's safer than no_plan or do

              • Hypocrisy…? Nowhere did I say no_plan is bad nor did I talk about “allowing” implicit done_testing. I said the latter is pointless and redundant when we already have no_plan. If it’s bad, then that’s only because it might mislead people into thinking they’re safer than with no_plan.

                Having a plan or not is a trade-off. It’s not about morals. If you don’t want to declare a plan, use no_plan. That’s what it’s for: to state your choice of trade-off cle

                • But if leaving off the no_plan gets you an implicit done_testing(), you don't need the boilerplate.

                  subtest 'one' => sub {
                    plan 'no_plan';
                    # bunch 'o tests
                  };

                  subtest 'two' => sub {
                    plan 'no_plan';
                    # bunch 'o tests
                  };

                  subtest 'three' => sub {
                    plan 'no_plan';
                    # bunch 'o tests
                  };

                  subtest 'four' => sub {
                    plan 'no_plan';
                    # bunch 'o tests
                  };

                  What's the point of that cut-n-paste code? I see no added value there. Most programmers that I know don't want to handle bookkeeping code, they want to program.

                  • Oh. For some reason I thought the 'with plan' and 'without plan' were syntax, not test names.

                    Hmm, that syntax seems to punish plans unnecessarily. How about requiring a plan to be declared up front something like this?

                    subtest { plan => 3 }, 'blah blah' => sub { ... };

                    Or maybe

                    subtest_noplan 'blah blah' => sub { ... };
                    subtest_plan 3, 'blah blah' => sub { ... };

                    Then it’s knowable whether there is a plan or not before invoking the sub, so the subtest can use no_plan instead of implicit don

                    • That sounds like a nice idea. The syntax is still a bit noisy, but still better than what's there. I'll give that a thought.

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.