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.
  • ...and now it makes plans almost irrelevant.
    This is one of those bits of yak shaving that Perl programmers seem to think is necessary. It always baffled me, even when I was a full fledged Perl guy, that I had to specify my plan up front. Just run the tests I give you!
    • So how do you know you didn’t run fewer tests than you meant to?

      Yes, OK, that was easy. Now tell me how you know you didn’t run more tests than you meant to.

      • Just how are you supposed to know how many tests you planned?

        Anyway... how about an end marker, "yes I'm done", a sub you call at the end of your test file. All it has to do is set a flag in the test module.

        done;
        If the tests are interrupted, it won't get called, and then you'll know, as the test module will check the status of that flag in its END block.

        Something like that.

        • Just how are you supposed to know how many tests you planned?

          What am I supposed to say to that?

          If the tests are interrupted, it won’t get called, and then you’ll know

          Right, that was the easy part I talked about.

          • What am I supposed to say to that?

            What I was aiming as was that with the old school test modules, you have to state how many tests you plan on executing. But how can you know? Counting them manually? Running the tests, toping they all get executed, and check how many were done in the error message?

            That is not ideal. I'd even prefer a dry run, using ok/nok to just count the tests without actually doing them, to this. Maybe do the real test in a live run immediately after that.

            • When you read this, the number one thing to remember is to take it with a grain of salt! Whether or not you choose to adopt a plan depends on whether or not you feel it brings enough added value to offset your dislike of it. If it doesn't, don't use a plan. I'm not dogmatic :)

              What I was aiming as was that with the old school test modules, you have to state how many tests you plan on executing. But how can you know? Counting them manually? Running the tests, toping they all get executed, and check how many were done in the error message?

              I've been trying to understand what you were meaning by this because I think that there's a miscommunication here. I could be wrong.

              If I'm presented with a 300 line test program, you're absolutely right that I can't just know that it's supposed to run 113 tests. I have to trust that the module author did the right thing.

              That being said, if I am the module author, then there's no real problem. I don't sit down and write a 300 line test program. I write the tests incrementally and every step of the way I know what's going on. So here are two ways that plans will save you in this scenario:

              use Test::More tests => 3;

              ok this_function();
              ok that_function();
              ok the_other_function();   # calls exit(0) internally

              Because the exit() gets called before the ok(), Test::More realizes we've not run enough tests. I've had this happen before where I'm using some module from the cpan which thinks calling exit is a good idea. Don't believe me? Try running this on your installed modules sometime:

              ack '^\s*exit\b' lib/perl5/

              Admittedly, many of those are false positives (documentation), but many of them are not.

              Another way a plan can save you:

              foreach my $attr ( $inspect->attributes($foo) ) {
                  can_ok $foo, $attr;
                  lives_ok { $foo->$attr } "... and we should be able to call '$attr'";
              }

              Now what happens if someone adds an attribute and forgets to update the plan? Some people say "yeah, just assert the number of attributes first". There's nothing wrong with that approach, but that means I always have to remember to do that when I have potentially varying number of tests. Or I can always assert a plan and never have to worry about it.

              • Running the tests, toping they all get executed, and check how many were done in the error message?

                I've been trying to understand what you were meaning by this because I think that there's a miscommunication here. I could be wrong.

                There was a typo that I noticed after I pressed "submit". What I wanted to say was tis:

                >Running the tests, hoping they all get executed, and check how many were done in the error message?

                There error message is, of course, the info of Test::* complaining about "It looks like you planned to run 20 tests, but you actually ran 23" so you can fix the plan number to 23.

                Or I can always assert a plan and never have to worry about it.

                My problem is that when I'm writing tests for a module, I may be adding a test every few minutes and I always have to update the plan. And t

                • You can get around that too.

                  use Test::More;
                  plan tests => my $num_tests;

                  BEGIN { $num_tests+=2 }
                  is( 1, 1, 'identity' );
                  isnt( 1, 2, 'identity' );

                  BEGIN { $num_tests++ }
                  is( 1 + 1, 2, 'addition' );

                  # etc
                  • That's clever! And it is possible because plan is a runtime function call, instead of the usual parameter to the use statement.

                    I must say, that plan is well hidden in the docs [cpan.org]. It doesn't even get its own entry in the module's list of functions.