Start outside-in, then decompose to unit tests over time. Most code bases interface with something with a relatively stable/published interface. Like a databas

Start outside-in, then decompose to unit tests over time. Most code bases interface with something with a relatively stable/published interface. Like a database or network library. If you can find these points, you can mock where you interact with the outside world, then test the entire code base end to end. Over time you can refactor the insides to be more decomposed and testable. As an example, a code base I worked on involved interacting with network firmware, then sending events to a UI for display. It also received these commands from the UI and told the firmware to do certain things. With some work, we could mock the source and sink of these APIs and inject them as dependencies (instead of instantiating directly). This let us test our huge ball of code to see if it did what was expected. Did the code send the right message to firmware when it got certain UI commands? Did it get in a good or bad state when the firmware responded incorrectly? This took a bit of work to mock and isolate how our code talked to these interfaces, but once in place, it was a game changer. We could pretty easily isolate problems in our codebase and recreate issues in a testable way. Then we would take the next step and decompose further, usually on a case by case basis, depending on the cost/benefit of refactoring. But it’s not realistic you’ll get to everything being decomposed in a legacy system.