working-with-legacy-code

Follow the five-step legacy code change algorithm: identify change points, find test points, break dependencies with minimal signature-preserving edits, write characterization tests that pin current behavior, then make your change. Never mix refactoring and behavior changes in one commit.

A characterization test documents what code actually does, not what it should do. Write an assertion you know is wrong, run it, read the failure message to learn the real behavior, then change the assertion to pin that observed value. Repeat until every branch your change touches is covered.

Use Parameterize Constructor: add constructor parameters for the dependencies with production defaults, so existing callers compile untouched while tests inject fakes. Extract Interface on heavy collaborators and Introduce Instance Delegator for statics are complementary moves.

Module mocking like jest.mock or unittest.mock.patch is a link seam that works well for getting first tests in place quickly, but it couples tests to file layout. For code you will keep changing, parameterizing constructors leaves better design behind and survives renames.

Pin the buggy behavior with a loud comment and a ticket number, then fix it later as a separate deliberate change. Silently fixing bugs during characterization is an unreviewed behavior change, and downstream code may depend on the wrong behavior.

The Skill argues big-bang rewrites ship late and miss years of edge cases while the old system keeps moving. Incremental cover-and-modify grows coverage along the paths you actually change, which is the only testing budget that reliably exists.