Ответ.

Автоматизация тестирования legacy-кода — одна из наибольших классических проблем в области ИТ.

История вопроса: Многие компании сталкиваются с необходимостью тестировать системы, которые писались без учета будущей автоматизации. Часто такие проекты имеют слабую документацию, высокий технический долг и нехватку изолированных компонентов.

Проблема: Главные сложности возникают из-за

отсутствия тестовых хуков и точек интеграции
невозможности изоляции данных для тестирования
сильной взаимозависимости модулей
большого числа аномалий и изменений, не отраженных в коде

Решение: Обычно процесс идет пошагово:

Анализ системы: требуется определить критичные бизнес-процессы и согласовать зону покрытия автотестами.
Внедрение тестовых точек: по мере возможности часть кода оборачивают прокси, адаптируют под тестовые двойники или используют паттерн dependency injection.
Пошаговое покрытие автотестами: пишут сначала тесты для самого "простого" и наименее связанного кода.
Постоянная поддержка и рефакторинг: после добавления тестов использую их как страховочную сетку для улучшений.

Ключевые особенности:

Тесты часто начинают писать не с нуля, а с "обёрток" над существующими функциями.
Необходимо поэтапно добавлять тестируемость в архитектуру.
Бизнес должен быть максимально вовлечён в регламентацию критичных сценариев.

Вопросы с подвохом.

Можно ли начать писать автотесты до полного рефакторинга legacy-кода?

Да, зачастую автотесты нужны именно для того, чтобы обезопасить рефакторинг. Нельзя ждать полной "идеальности" — наоборот, тесты помогают смело меняться.

Стоит ли сразу пытаться покрыть весь legacy-код автоматическими тестами?

Нет. Нужно фокусироваться на самых рисковых и часто используемых сценариях. Покрытие "всего подряд" вредит скорости и смысла не имеет.

Обязательно ли внедрять современные паттерны вроде DI, чтобы тестировать legacy-код?

Нет, но их рекомендуется использовать, если позволяют ресурсы. Первый шаг — хотя бы частичная изоляция, моки и специальные тестовые точки в коде.

Типовые ошибки и анти-паттерны

Миграция всего кода сразу под автотесты — проекты останавливаются и теряют бизнес-смысл.
"Параноидальное" покрытие незначимых функций.
Отсутствие коммуникации между разработкой, тестированием и бизнесом.

Пример из жизни

Негативный кейс

Команда попыталась внедрять автотесты, переписав всё старое приложение под паттерны SOLID и охватив тестами 100% кода.

Плюсы:

Базовое улучшение архитектуры.
В долгосрочной перспективе тесты могут принести пользу.

Минусы:

Простой разработки несколько месяцев.
Постоянные баги и рассинхронизация с требованиями бизнеса.
Утрата актуальности кода к моменту, когда тесты написаны.

Позитивный кейс

Внедряли автотесты только для ключевых точек расчёта подряд с внедрением специальных стабов, минимально меняя общий код.