in reply to testing code

For testing modules, Test::More is the main module that I use. Test::Exception is probably my second most used because I got bored of writing eval blocks to catch die.

Generally, I try to write as many of my tests as possible before coding. That way I know how the API of my modules will work, and I can catch an ugly API before I would be able to otherwise. Then, I write code for the modules and make sure I get all my tests to pass without warnings. After that, I run Devel::Cover over it all to make sure I've got good test coverage, and add test cases as needed.

Replies are listed 'Best First'.
Re: Re: testing code
by geekgrrl (Pilgrim) on May 05, 2004 at 22:57 UTC
    ooh.. cool new modules to try. thanks!

    I definitely want to try out Test::Exception - I'm often using eval blocks. And Devel::Cover looks quite interesting. I haven't thought about using coverage reports before.

    One of these days I know I should graduate up to Test::More, but i've been holding off so far...it's that laziness factor, i guess, and Test::Simple is just so...simple and easy.

    Update: I've switched my eval blocks over to use Test::Exception routines like throws_ok and lives_ok. It makes the code much more readable, and saves me some typing, too.
[reply]
      We use Test::More all the time.

      Every <module>.t we write has a corresponding t/<module>.t test file written for it.

      I've included a real Makefile.PL from one of our projects, and a sample Test::More template .t file.

      You should also read the ExtUtils::MakeMaker doco for more sophisticated ways of calling make test 

      # Makefile.PL
use ExtUtils::MakeMaker;

WriteMakefile(
              NAME         => 'txu_bims',
              VERSION_FROM => 'VERSION.pm',
              test         => {TESTS => './TXU/BIMS/t/*.t ./TXU/t/*.t'
+}, # how to pass multiple test paths
              PMLIBDIRS    => ['./TXU/BIMS', './TXU'],
              PREREQ_PM    => {
                               Log::Log4perl => 0.36,
                              },
             );

      [download]
      # template Module/Under/t/Test.t
#!/usr/bin/perl -w

use strict;

use Test::More qw(no_plan);

use Module::Under::Test;

# test go here
my $obj = Module::Under::Test->new();
isa_ok($obj, 'Module::Under::Test');

is($obj->method(), 'expected output', 'standard test');

is_deeply($obj->meth_retn_ref(), {complex => {structure => ['here']}},
+ 'method returns ref to complex structure');

      [download]

      After this, its as simple as ... 

      perl Makefile.PL
make test

      [download]

      More complex examples of calling make test are ...

      • make test TEST_VERBOSE=1
        for more detailed information on test execution
      • make testdb TEST_FILE=path/to/script.t TESTDB_SW=-d:ptkdb
        to run just path/to/script.t under the GUI debugger ptkdb (which is a great debugger

      *UPDATE* - proxy dropped out half way through uploading this - added the point list

      +++++++++++++++++
      #!/usr/bin/perl
      use warnings;use strict;use brain;

[reply]
[d/l]
[select]
Re: Re: testing code
by geekgrrl (Pilgrim) on May 07, 2004 at 19:05 UTC
[reply]
      I'm wondering why I should think about switching from Test::Simple to Test::More.

      If you're doing anything non-trivial it will probably help.

      What is it that gives Test::More its "Moreness" ?

      It gives you more expressive ways to talk about your tests. So instead of saying:

      ok ( $foo =~ /bar/, 'contains bar');
ok ( UNIVERSAL::isa($o, 'MyClass'), 'isa MyClass' );
ok( $foo eq 'bar', 'equals bar' );

      [download]

      you can say

      like( $foo, qr/foo/, 'contains bar' );
isa_ok( $o, 'MyClass' );
is( $foo, 'bar', 'equals bar' );

      [download]

      which is marginally easier to comprehend. You also get more informative test failures, for example if you do:

      is( 'apples', 'oranges', 'expecting to find some oranges' );

      [download]

      you'll get the informative

      not ok 1 - expecting to find some oranges
#     Failed test (-e at line 1)
#          got: 'apples'
#     expected: 'oranges'

      [download]

      rather than just

      not ok 1 - expecting to find some oranges

      [download]

      You'll find the same sort of advantages with other Test:: modules. You get to express you test more precisely and you get better feedback on test failures.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom