You don't need to make your distribution look like the structure that h2xs gives you, so stop worrying about h2xs. You can look at other utilities, like Module::Starter. You might want to create a fake distro just to see what it does and how it works. In the same way, you don't need a Makefile.PL to test, although it does help. You want to get there eventually, but if testing is more important at the moment, you can skip it for now.

You can use the prove(1) function that comes with Test::Harness. You tell prove where to find the modules, and which test files to run, and it handles the rest. If you write the tests first, this is the quickest way to get going.

I suggest that you start off so that you can move towards a Makefile.PL (or a Build.PL if you want to use Module::Build instead]. Put all of your tests in a directory named t since that's where Makefile.PL and Build.PL look for them by default.

As for writing the tests, I like to make a lot of small test files, usually one per function in the public interface at least. That's mostly a matter of taste. With prove, you can limit your tests to just the files you want, so if you have a lot of test files with a small number of tests, you can break down your testing easily. With only a couple of test files that each have a large number of tests, you might have to sit through a lot of tests that you don't care about at the moment.

Once you are ready to create the Makefile.PL, I suggest you look at a couple on CPAN and find one that looks simple and close to what you want, then copy it. You'll be able to tell Makefile.PL where to find the modules (they don't have to be in a lib/ directory), where to put other files like executables, and so on. The ExtUtils::MakeMaker documentation has all of the details, and don't let it scare you off in the first two minutes. ExtUtils::MakeMaker::Tutorial will help too, as will perlmodstyle and perlnewmod.

As for creating good test cases, look around and you'll find a lot of advice on testing. Good luck :)

You will want Test::Harness and Test::More. You probably already have them.

The easiest way to get started with those modules is to just examine the t/ directory of some CPAN module distributions. After that, take a look at the Test::More perldocs.

A recurrent bug can be swatted for good by turning the code fragment which triggers it into a short series of tests. Just compare the expected values to the actual ones for known input values. The test suite will then check for regressions each time it is run.

A Makefile.PL is a good thing to have, and not just for running the test suite, but you can also just call the runtests function of Test::Harness, $ perl -MTest::Harness -e'runtests @ARGV' t/*.t

Additionally, for a gentle introduction to the nuts and bolts of testing using Test::More check out Test::Unit::Tutorial

--
Scott.

• Unit tests - these make sure that foo() accepts a number and outputs a string ... the basic lowest level tests.
• Subsystem tests - these make sure that Foo::Bar does what its supposed to do. You will probably end up using some mock objects here. (Test::MockObject and DBD::Mock will probably be helpful.)
• Integration tests - these make sure that Foo::Bar and Foo::Baz play nicely together. These are really complicated. Don't start here.
• System tests / Acceptance tests - you may not be able to to do these in Perl. Often, you need some outside framework, such as TestRunner or Rational Rose. Also, the developer isn't a good person to do system tests.

This topic has come up a lot in the Monastery. A few of the more notable threads (in no particular order):

• What is the best way to add tests to existing code? (It references a ton of good threads)
• No plan "weakens" my Test scripts?
• Test::More usage to test functions that die
• How a script becomes a module
• Testing that functions are imported
• RFC: Tutorial on Testing
• Using DBD::Mock for testing DBI related code
• Create smoke test for your directory of modules
• Organising Large Test Suites

I've been creating a fake distro with ExtUtils::ModuleMaker lately, and have been relatively pleased with the results. I haven't completely translated the fake distro into my existing codebase yet, but that's my next step.

Most of the suggestions so far have focussed on standard Perl testing, which is generally unit testing. I'll offer a different option. You mention CGI scripts, so you could build tests to excercise the interface. Take notes on how you have found previous bugs through the browser. Then you can look into automating that sequence using WWW::Mechanize and Test::WWW:Mechanize.

We did this for a large amount of existing web code because in addition to not having tests, much of our older code wasn't very 'testable.' Creating new unit tests would have involved a lot of refactoring because the code wasn't modular. Building tests of the interface was much easier and effective.

Then, moving forward, consider all of the advice above. Each time you add code or fix a bug, make the code very modular and testable and write tests for it. That way you will be in good shape moving forward. If you take this approach when you fix bugs, your 'buggy' code will start to have much better coverage and you'll experience many fewer bugs.

Thanks all who contributed,

A wealth of information to look into, and all of it seems very relevant to what I am trying to achieve. Am sure many more questions on testing to come, thanks for now.