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.

Use Parameterize Constructor: add constructor parameters for the dependencies with production defaults, so existing callers compile unchanged while tests inject fakes. Extract Interface on heavy collaborators first if their concrete types are hard to fake.

A seam is a place where you can alter program behavior without editing that code, such as an overridable method, a module import, or a build flag. Every seam needs an enabling point reachable from your test where you choose which behavior runs.

No—pin the buggy behavior with a comment and file a ticket instead. Downstream code may depend on the wrong behavior, so fix it later as a deliberate, separate behavior-change commit that flips the assertion and the code together.

Use them when you cannot get the host code under test today. Sprout puts new logic in a fresh, fully tested method or class called from one line in the legacy code; Wrap renames the old method and adds behavior around it, decorator-style.