Re: What goes in a test suite?

If you've not come across them already take a look at Test::Simple, Test::More and Test::Tutorial.

You might also find Test::Class of interest (but since I wrote that one I may be biased :-)

As to what you test - I tend to write all my code "Test First". Basically this means:

I write the test for what I want my code to do.
This (of course) fails since there isn't any code yet.
I then write code until my test passes.
Then, since I know I've finished and can move along to the next piece of functionality that needs testing.

Works very well for me. I get into the coding "flow" much faster this way and end up with very robust code.

Test suites also make changing your code a much less stressful business since you immediately know if you've broken anything.

I always have a window open that sits there doing a make test every time any file in my project changes. Instant feedback. Very handy.

This style comes from Extreme Programming (also known as XP - just be be confusing). If you're interested take a look at extremeprogramming.org.

Retrofitting a test suite on an existing code base can be a much more painful task. Two approaches that have worked for me are:

Testing the documentation (Test::Tutorial has an example of this).
Write tests for any bit of code that you need to change. That way you can check that you don't break anything as you make the change, and you will gradually build up a set of tests for the whole code base.

Comment on Re: What goes in a test suite? Download Code

Replies are listed 'Best First'.
Re: Re: What goes in a test suite? by DapperDan (Pilgrim) on Aug 11, 2002 at 11:22 UTC
I always have a window open that sits there doing a make test every time any file in my project changes. how do you do this?	[reply]
Watching tests... by adrianh (Chancellor) on Aug 11, 2002 at 13:41 UTC
I have this sitting in my ~/bin #! /usr/bin/perl -w # onchange file ... command # run command if any of the given files/directories # change use strict; use warnings; use File::Find; use Digest::MD5; my $Command = pop @ARGV; my $Files = [@ARGV]; my $Last_digest = ''; sub has_changed { my $files = shift; my $ctx = Digest::MD5->new; find(sub {$ctx->add($File::Find::name, (stat($_))[9])}, grep { +-e $_} @$files); my $digest = $ctx->digest; my $has_changed = $digest ne $Last_digest; $Last_digest = $digest; return($has_changed); }; while (1) { system($Command) if has_changed($Files); sleep 1; }; [download] I have this in my `.cshrc` `alias testwatch "onchange Makefile.PL Makefile /.pod /.pm .pm t t +est.pl 'clear; make test \!'"` [download] I then type `% testwatch` or `% testwatch TEST_VERBOSE=1` in the root directory of any module I'm messing with. This won't work 100% of the time but hits that 80/20 spot for me. I have a little todo list on an improved test monitor that I will, when some of that mythical free time comes along, implement. Now we have the lovely Test::Harness::Straps it's not even that difficult.	[reply] [d/l] [select]