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):
- 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):
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?.
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.
| & || & |
| < || < |
| > || > |
| [ || [ |
| ] || ] ||