Manual or unit testing for legacy code

It is often necessary to make changes to a legacy code base. It is also often the situation that no unit tests will exists for this code base.
Unit testing should be part of all code that is written. So, it is, of course, desirable to add unit testing around any code you add or change to the legacy code base. (Working on the assumption that it is not a practical use of time to add unit testing to all existing code.)

Unfortunately existing code is sometimes written in a way that makes unit testing very difficult. (Usually because of a poor object design and a very high number of dependencies.) This means it may be a better use of time to create a test script which can be manually followed, rather than a series of tests which can be automatically run.

But, how do you know when to create an automated test? and when to create a manual script?

Simple. Always create an automated test. Unless creating the automated test will take ten times longer than writing and executing the manual script.

Why ten times?
Because the test will need to be run:

• Once before any changes are made, to capture current behaviour.
• At least once while making the change. (probably a lot more!)
• At least twice during the testing/QA phase.
• Every time a version of any program using the code is released.
• Every time any code that the changed code is dependent on is changed.

This will add up to at least ten times very quickly.