Start from functional tests.

Make sure you have control on the data that is fed to the system and
on its configuration.

Then run the system and automatically save the results to file.
Next time you make a change to the code you can run the system with
the controlled configuration and data set and check that the new
output are still equal to the old outputs.

While this will not tell you where the error is, it can give you the
confidence that the code has not been broken.

After you have this under control you can start refactoring with this
safety net and proceed isolating and testing smaller and smaller
chucks of code.. down to unit tests.

I have produced a Vba framework that helps me doing this with excel
and it works quite well.

On 4/4/06, Charlie Bowman <charlie / castlebranch.com> wrote:
> The test plans are for a massive curses application (over 200,000 lines
> of code).  Most of the code is very old and not very testable.  Most of
> the code doesn't even use sub routines (perl).  I'm not sure that it is
> feasible to modify all the code to make unit tests possible.  It would
> just take too long and I'm not in a position to make that decision.  I'm
> just trying to get a good test plan ready so that the application can be
> tested by QC.

--
Chiaroscuro
---
Liquid Development: http://liquiddevelopment.blogspot.com/