in reply to Using Test modules in production scripts
What you are dealing with is the problem of how to effectively test legacy code. There has, in fact, been a large amount of material published over the years on this very topic, and you should carefully review some of it before proceeding.
Perhaps the first question you should consider is ... what are you testing for? And, why? In a later post you suggest that one reason might be that you intend to port this application to another operating environment and therefore need to ascertain whether it will run there. You should carefully consider, and enumerate, all of these motivations.
It has been said, with regard to legacy code, that the question is not whether the code works “correctly,” but whether or not it now works “differently.” The tests for an existing application might be focused, for example, on how the program deals with its environment, and how its responses vary given different sets of inputs. Tests that try to delve into the mysteries of “mysterious code that (according to the business...) is working,” might not be appropriate at all, especially given the very real risk of de-stabilizing it. (And thus, ex minimis, of invalidating your tests.)
There are various strategies ... “black box,” “white box,” “glass box,” “mock testing,” and many more ... which are properly beyond the scope of this reply. Time to do some googling, first.
| Replies are listed 'Best First'. | |
|---|---|
|
Re^2: Using Test modules in production scripts
by locked_user sundialsvc4 (Abbot) on Feb 15, 2011 at 14:58 UTC |