in reply to Eliminating duplicated code in multiple test scripts using Test::More

G'day eyepopslikeamosquito,

One issue I see with this is that you need to know how many tests are in TMod::sub1() in order to specify tests => 5 in t1.pl. If that's intended to be common code, then whenever the common code changes all test scripts that use it will also need to be changed.

One way around this would be to use Test::More's subtest() function. Consider this slight rewrite of the code you posted.

t1.pl:

use strict;
use warnings;

use FindBin ();
use lib "$FindBin::Bin";
use TMod;

use Test::More tests => 4;

ok( 1 == 1, "mytest1" );
subtest tmod => sub { TMod::sub1() };
ok( 3 == 4, "mytest3" );
ok( 4 == 4, "mytest4" );

[download]

TMod.pm:

package TMod;
use strict;
use warnings;

use Test::More;

sub sub1
{
    plan tests => 2;

    ok( 'sub1' eq 'sub99', "sub1-test1" );
    ok( 42 == 42, "sub1-test2" );
}

1;

[download]

Sample run:

$ perl t1.pl
1..4
ok 1 - mytest1
    1..2
    not ok 1 - sub1-test1
    #   Failed test 'sub1-test1'
    #   at /Users/ken/tmp/pm_subtest_mod/TMod.pm line 11.
    ok 2 - sub1-test2
    # Looks like you failed 1 test of 2.
not ok 2 - tmod
#   Failed test 'tmod'
#   at t1.pl line 11.
not ok 3 - mytest3
#   Failed test 'mytest3'
#   at t1.pl line 12.
ok 4 - mytest4
# Looks like you failed 2 tests of 4.

[download]

With this setup, you can add, remove or change the tests in TMod::sub1() without ever needing to change any of the calling scripts. You could also pass arguments to TMod::sub1() to control which tests are run with sub1() dynamically determining the value for plan tests => $num_tests; (again, without requiring any changes to the calling scripts).

-- Ken

Replies are listed 'Best First'.
Re^2: Eliminating duplicated code in multiple test scripts using Test::More
by TomDLux (Vicar) on Jul 22, 2013 at 04:44 UTC

    The modern way is to simply invoke use Test::More; at the top, and at the end have done_testing().

    If there were problems, they would generate error messages, which are detected by TAP; if there are no errors, the system counts up the successful tests and uses that in the final message.

    As Occam said: Entia non sunt multiplicanda praeter necessitatem.

[reply]
[d/l]
[select]
      It is probably modern not to comment out tests. When I do such an ancient thing, I am often glad that Test::More reminds me to uncomment them later when the number of tests does not match.
      لսႽ† ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ
[reply]

      While I'm aware that done_testing($number_of_tests) is a newer addition to Test::More (and, as such, could be referred to as a modern way), I'm not convinced that using done_testing() is the modern way. I can see that I'm possibly misinterpreting your intent: perhaps you could clarify, particularly with respect to any special situations or conditions that you considered implicit in your statement.

      ++choroba makes a good argument for specifying the number of tests. Another, which has certainly happened to me, is being interrupted in the process of writing a series of planned tests and then, on resumption of the task, accidentally skipping one that hadn't been written yet: specifying the number of tests up-front catches that too.

      Test::More's documentation, in the (cutely named) "I love it when a plan comes together" section, has "The preferred way to do this is to declare a plan ..."; and later, in the done_testing bullet point, "This is safer than and replaces the "no_plan" plan.".

      -- Ken

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom