This is sort of off-topic because it's more a general question about testing, rather than Perl specific, but the code in question happens to be written in Perl...
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. A colleague's view is that you can't have functional tests until you know that the individual units work, hence start with unit tests. (I believe that the assumption is that when they're mostly complete start on functional tests, but that wasn't stated). This seems the logical approach if you want to refactor things. My view is that because 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). Also, right now we really don't care about the specific output of the the individual units that make up the code - all that matters to the client is the final behaviour. Hence writing unit tests at fine detail for existing code could well be a (relative) waste of effort in that it's quite possible that the units they test are thrown away soon if the implementation is changed. Whereas functional requirements are much less likely to change on a release-by-release basis, so writing them is less likely to generate code that has a short lifetime. And having functional tests is likely to give us better coverage up front, so we're more likely to spot a change that unintentionally breaks behaviour, even if we can't use them to efficiently nail down which change was the culprit. Why am I wrong? Nicholas Clark
