Why not refactor XXX into ZZZ...

The Long Story

My team has inherited a large codebase of resource libraries. Due to the man-years required to refactor this into something that fits the use model, the team is making use of the existing codebase. (Eventually, something may replace it, or we may move on to something completely different.)

This is a system to test real hardware, firmware, and software in multiple systems communicating with each other, the test controller, and other interested auxilliary systems. The core of the codebase is an "event loop" system that polls multiple remote systems, registers events to trigger at specific times, and registers signal handlers listening for certain kinds of responses. (Some issue with threads was apparently encountered at inception, so this is a polling system using RPC or somesuch.)

Our current aim is to write stand-alone tests for various components and features. The base class that all tests use is capable of handling nested tests, such that with a little forethought, all tests can be run concurrently in the "event loop" system. The base class registers all nested tests, and runs through all setup methods, then all initiate methods, then all complete methods, then all teardown methods. While the execution path is not threaded, multiple events on multiple systems can occur concurrently or simultaneously (depending on the nature of the events). Properly structured tests are written as modules, which can then be used (nested) in other tests, ad nauseum.

The point of my question was to discover a practical way to layer tests upon tests, with minimal rewriting of existing tests. Since everything is in a formal system with code reviews and releases, it is important not to go refactoring big swaths of code to add a minor bit of coverage to the suite of tests.

I've swept a lot of details under the rug, and while there is some leeway to change direction, we can't incur a lot of refactoring time. There is a moderate but growing list of test scripts, so any global refactoring decision should be made as soon as possible.

Ultimately, I think we'll have to refactor the big methods into smaller ones, and call into the parent(s) at a refined level to do only the bits needed, and not just rewrite a larger method (with considerable duplication). (I've probably left something out, but I'll stop here for now.)