in reply to Writing tests when you don't know what the output should be
Retrofitting tests is never fun. The better approach is to develop the tests along with the code. Usually that means write a tests for the function you are about to write. Write the function and fix tests and the function until all the tests succeed. Often that means that you will have to "mock" input data that doesn't exist yet, or other functions that don't exist and so on.
An important part of the process is to measure the code coverage provided by the tests. That is, measure how much of the code under test is actually hit by the tests. Devel::Cover is the tool of choice for coverage analysis, but it needs a bit of getting your head around.
This "tests first" technique is known as Test Driven Development and is a popular choice for Perl and agile developers. Ideally the tests and the code are written against documented interfaces without direct reference to each other. In a development team context there may be three different devs involved: API doc writers, test writers and code writers. Training yourself to wear only one of the three hats at a time helps the process work for a single dev.
|
|---|