Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options

Re^2: RFC: Test::Block

by adrianh (Chancellor)
on May 07, 2003 at 16:28 UTC ( #256284=note: print w/replies, xml ) Need Help??

in reply to Re: RFC: Test::Block
in thread RFC: Test::Block

So when a developer or somebody wishes to run the full test suite, they have to modify a test file? They can't just do something like `make test TEST_ALL=1'?

Nope :-)

I think you're misunderstanding the purpose. It's not restricting the tests run, but allowing you to specify the number of tests at a finer level of detail.

Some examples of where this may be useful:

  • When you have a large test suite keeping the number of tests in the plan in sync with the number of tests in the script can become annoying, since the plan is specified at the top of the script. Lots of scrolling up and down. With Test::Block you can keep the number of tests close to the tests. So instead of:

    use Test::More tests => 100; isa_ok my $o = Foo->new, 'Foo'; lives_ok { $o->foo(42) } 'can set foo'; is( $o->foo, 42, 'foo set' ); # 95 other tests lives_ok { $o->bar(42) } 'can set foo'; is( $o->bar, 42, 'foo set' );

    you can do:

    use Test::More 'no_plan'; { my $b = Test::Block->expecting(1); isa_ok my $o = Foo->new, 'Foo'; }; { my $b = Test::Block->expecting(2); lives_ok { $o->foo(42) } 'can set foo'; is( $o->foo, 42, 'foo set' ); } # 95 other tests { my $b = Test::Block->expecting(2); lives_ok { $o->bar(42) } 'can set foo'; is( $o->bar, 42, 'foo set' ); }
  • It can make maintaining SKIP blocks easier. For example if you have:

    SKIP: { ok(1); skip "skip tests", 2 if $foo; ok(2); skip "skip tests", 1 if $bar; ok(3); };

    and add another test at the end of the block you have to change both skip calls to take the new test into account. With Test::Block you would only have to alter the number of expected tests:

    SKIP: { my $b = Test::Block->expecting(4); ok(1); skip "skip tests", $b->remaining if $foo; ok(2); skip "skip tests", $b->remaining if $bar; ok(3); ok(4); };
  • If part of your test script runs an indeterminate number of tests then you have to make you're entire script 'no_plan' - negating the possible advantages of having a predetermined plan. With Test::Block you can check that the fixed tests actually run as expected.

  • With some test scripts you can only determine the number of tests at runtime. This can lead to complex plans like:

    plan tests => @foo + keys %bar + (3*$ni);

    where the plan is a long way from the tests. With test block you can localise the plans with the tests.

    { my $b = Test::Block->expecting(scalar(@foo)); # @foo tests } { my $b = Test::Block->expecting(scalar(%bar)); # %bar tests } { my $b = Test::Block->expecting(3 * $ni); # $ni tests }
Sure I can somehow code that into my test scripts, but why should (your module is too short, it needs more features)?

What else should it do? Personally I don't think that "too short" is a criticism ;-)

Replies are listed 'Best First'.
Re: Re^2: RFC: Test::Block
by jplindstrom (Monsignor) on May 07, 2003 at 17:59 UTC
    Your examples makes excellent sense along the lines of

    The principle may be stated formally as if it were a Newtonian Law of sorts:
    The likelihood of keeping all or part of a software artifact consistent with any corresponding text that describes it, is inversely proportional to the square of the cognitive distance between them.
    A less verbose, less pompous description would be simply: Out of sight; out of mind!

    Therefore, it is desirable for us to try and minimize the cognitive distance between artifacts and their descriptions!


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://256284]
[marto]: good morning all

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (9)
As of 2018-05-22 07:07 GMT
Find Nodes?
    Voting Booth?