At a very, very high level testing involves (a) defining sample inputs (b) defining expected outputs (c) comparing actual outputs to expected outputs. A very good starting point for understanding the basic testing pattern is the documentation included in Test::Simple.

However, as you are noticing, applying that scenario to real world testing problems isn't quite so simple. Reading through your example, it seems you have two separate issues:

• how to emulate the real world environment in a controlled fashion without spending too much time setting up and tearing down the test environment.
• how to organize suites of tests so that you can easily target problem areas

There are thousands of modules in the CPAN Test namespace and figuring out how they might apply to your testing needs can be overwhelming.

First, the standard test environment is centered around Test::More and App::Prove. In its standard usage, you define one or more test suite files. These files are normal script files except that they end in .t rather than .pm or .pl. A test suite is simply a collection of assertion statements stored in a single file and run start to finish. When written in a traditional fashion, the beginning of the file stores set up instructions. This is followed by a sequence of assertions. The test suite script ends with the tear down code. The scripts are run singly or as a group using the prove command.

Out of the box these tools are primarily suitable for testing modules containing a set of functions with minimal set up and tear down. Your testing needs are more complicated, but fortunately there are several modules designed to help you gain more control over setup, teardown, and selective execution of tests.

• To better manage set up and tear down for a collection of test script files, you can define your own version of the 'prove' command - see App::Prove for details.
• If you have a lot of tests defined between setup and tear down of your controlled environment, you may want to consider working with one of the modules for selectively running tests: Test::Steering, Test::Tagged, Test::Less or Test::Usage.
• There are also several modules designed to help with setting up and tearing down controlled database environments. Among the modules (this list is not complete):
  • Test::DBIC - lets you test not-yet-released DBIx modules
  • Test::MockDBI - creates fake DBI interface for testing
  • Test::Database - manages set up of test databases
  • Test::TempDatabase - automate creation and dropping of test databases
  • Test::Fixture::DBIC::Schema - load fixture data to storage
  • Class::DBI::Test::TempDB - maintains an SQLite database for testing CDBI
  • DBICx::TestDatabase - create a temporary database
  • Rose::DBx::TestDB - creates test Rose::DB::Object modules backed by a temp sqlite database
• Finally, there are modules that can speed up the process of setting up inputs and comparing actual and expected outputs (again, this list is not complete):
  • Test::DBICSchemaLoaderDigest - makes sure programmers haven't fiddled with the digest key for DBICSchema
  • Test::DatabaseRow - tests database query results against arrays
  • Test::CDBI::Basic
  • Test::DBIx::Class::Schema - verifies that a DBIx class has all expected methods

If time spent writing tests is a problem, you may also want to check out some of the answers on the recent thread Lazy test writing?.

Best, beth