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.

            • But how can you know?

              How much confidence do you have in a test if you don't know exactly what you expect it to do?

            • 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

              • 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.