|laziness, impatience, and hubris|
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:
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.
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?.