Answer.

Automating the testing of legacy code is one of the biggest classic problems in the IT field.

Background: Many companies face the necessity of testing systems that were written without considering future automation. Often, such projects have poor documentation, high technical debt, and a lack of isolated components.

Problem: The main difficulties arise due to

lack of test hooks and integration points
inability to isolate data for testing
strong interdependencies of modules
a large number of anomalies and changes not reflected in the code

Solution: Usually, the process proceeds step by step:

System analysis: it is required to identify critical business processes and agree on the coverage area of automated tests.
Implementation of test points: as much as possible, part of the code is wrapped with proxies, adapted for test doubles, or uses the dependency injection pattern.
Step-by-step coverage with automated tests: tests are first written for the "simplest" and least coupled code.
Ongoing support and refactoring: after adding tests, they are used as a safety net for improvements.

Key features:

Tests are often started not from scratch, but with "wrappers" over existing functions.
Testability needs to be gradually added to the architecture.
The business needs to be maximally involved in regulating critical scenarios.

Tricky questions.

Can automated tests be started before fully refactoring legacy code?

Yes, often automated tests are needed to secure the refactoring. One should not wait for complete "perfection" — on the contrary, tests help to change boldly.

Should one immediately try to cover all legacy code with automated tests?

No. Focus should be on the most risky and frequently used scenarios. Covering "everything randomly" harms speed and makes no sense.

Is it mandatory to implement modern patterns like DI to test legacy code?

No, but they are recommended if resources allow. The first step is at least partial isolation, mocks, and special test points in the code.

Typical mistakes and anti-patterns

Migrating all code at once to fit automated tests — projects stop and lose business meaning.
"Paranoid" coverage of insignificant functions.
Lack of communication between development, testing, and business.

Example from life

Negative case

The team tried to introduce automated tests by rewriting the entire old application under SOLID patterns and covering 100% of the code with tests.

Pros:

Basic improvement of architecture.
In the long term, tests may bring benefits.

Cons:

Months of development downtime.
Constant bugs and desynchronization with business requirements.
Code becoming outdated by the time tests are written.

Positive case

Automated tests were introduced only for key calculation points along with the introduction of special stubs, minimally changing the overall code.