Nicholas Clark wrote:
There is this big hairball of under-tested code. (Nothing new here)
So the question is, which to tackle first - unit tests, or functional tests.
[snip]
the actual output of the code isn't well specified
(sadly nothing that new there either), if we write functional tests to
verify that the behaviour we desire is present, then we're actually killing
two birds with one stone - we have tests for the spec, and the tests are
the spec. (Which isn't perfect as specs go, but it's a heck of a lot better
than the current spec).
Write your documentation first. Then write your tests. Then refactor
the code.
You need an accurate specification of the code's current, non-deprecated
functionality. To do so, you will have to conduct a close analysis of
the current code. Once you've done that, you will quickly get an idea
of which tests you need to write first.
My hunch is that these will be "functional," at least in the sense that
you will be broadly testing the output of subroutines. But I admit that
I'm not entirely clear on the distinction you draw between functional
and unit tests.
In an event, once you've got your first tests in place, you can then use
Devel::Cover (or some other coverage tool for non-Perl code) to prune
unnecessary code and guide you in writing unit tests and in refactoring.
And you will already have written the core of your documentation!
Jim Keenan
