Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

Re: testing code

by Steve_p (Priest)
on May 05, 2004 at 22:44 UTC ( [id://350945]=note: print w/replies, xml ) Need Help??


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.
      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, }, );
      # 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');

      After this, its as simple as ...

      perl Makefile.PL make test

      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;

Re: Re: testing code
by geekgrrl (Pilgrim) on May 07, 2004 at 19:05 UTC
      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' );

      you can say

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

      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' );

      you'll get the informative

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

      rather than just

      not ok 1 - expecting to find some oranges

      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.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://350945]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others cooling their heels in the Monastery: (5)
As of 2024-03-29 15:06 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found