Marking Tests as TODO

     

Even though having a well- tested codebase can increase your development speed, you may still have more features to add and bugs to fix than you can program in the current session. It can be useful to capture this information in tests, though they'll obviously fail because there's no code yet! Fortunately, you can mark these tasks as executable, testable TODO items that your test harness will track for you until you get around to finishing them.

How do I do that?

Take a good idea for some code: a module that reads future versions of files. That will be really useful. Call it File::Future , and save the following code to File/Future.pm , creating the File/ directory first if necessary:

 package File::Future;     use strict;     sub new     {         my ($class, $filename) = @_;         bless { filename => $filename }, $class;     }     sub retrieve     {         # implement later...     }     1; 

The File::Future constructor takes a file path and returns an object. Calling retrieve( ) on the object with a date retrieves that file at the given date. Unfortunately, there is no Perl extension to flux capacitors yet. For now, hold off on writing the implementation of retrieve( ) .

There's no sense in not testing the code, though. It'll be nice to know that the code does what it needs to do by whatever Christmas Acme::FluxFS finally appears. It's easy to test that. Save the following code as future.t :

 use Test::More tests => 4;     use File::Future;     my $file = File::Future->new( 'perl_testing_dn.pod' );     isa_ok( $file, 'File::Future' );     TODO: {         local $TODO = 'continuum not yet harnessed';         ok( my $current = $file->retrieve( 'January 30, 2005' ) );         ok( my $future  = $file->retrieve( 'January 30, 2070' ) );         cmp_ok( length($current), '<', length($future),             'ensuring that we have added text by 2070' );     } 

Run the test with prove . It will produce the following output:

 $  prove -v future.t  future.t....1..4     ok 1 - The object isa File::Future     not ok 2 # TODO continuum not yet harnessed     #     Failed (TODO) test (future.t.pl at line 14)     not ok 3 # TODO continuum not yet harnessed     #     Failed (TODO) test (future.t.pl at line 15)     not ok 4 - ensuring that we have added text by 2070 # TODO           continuum not yet harnessed     #     Failed (TODO) test (future.t at line 13)     #     '0'     #         <     #     '0'     ok     All tests successful.     Files=1, Tests=4,  0 wallclock secs ( 0.02 cusr +  0.00 csys =  0.02 CPU) 

What just happened ?

The test file for File::Future marks the tests for retrieval of documents from the future as an unfinished , but planned, feature.


Note: Unlike skipped tests, tests marked as TODO do actually run. However, unlike regular tests, the test harness interprets failing TODOs as a success .

To mark a set of tests as TODO items, put them in a block labeled TODO , similar to the SKIP block from "Skipping Tests," earlier in this chapter. Instead of using a function similar to skip( ) , localize the $TODO variable and assign it a string containing the reason that the tests should not pass.

Notice in the previous output that Test::More labeled the tests with TODO messages and the TODO reason. The TODO tests fail, but because the test file set that expectation, the test harness considers them successful tests anyway.

What about...

Q:

What happens if the tests succeed? For example, if the tests exercise a bug and someone fixes it while fixing something else, what will happen?

A:

If the tests marked as TODO do in fact pass, the diagnostics from the test harness will report that some tests unexpectedly succeeded:

 $  prove -v future.t  future-pass....1..4     ok 1 - The object isa File::Future     ok 2 # TODO continuum not yet harnessed     ok 3 # TODO continuum not yet harnessed     ok 4 # TODO continuum not yet harnessed     ok             3/4 unexpectedly succeeded     All tests successful (3 subtests UNEXPECTEDLY SUCCEEDED).     Files=1, Tests=4,  0 wallclock secs ( 0.02 cusr +  0.00 csys =  0.02         CPU) 

This is good; you can then move the passing tests out of the TODO block and promote them to full-fledged tests that should always pass.



Perl Testing. A Developer's Notebook
Perl Testing: A Developers Notebook
ISBN: 0596100922
EAN: 2147483647
Year: 2003
Pages: 107

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net