День 1186. #ЗаметкиНаПолях
Код или Тесты: Что Рефакторить?
Сегодня рассмотрим, как рефакторить производственный код, если у вас нет достаточного покрытия тестами.

Все мы иногда работаем над устаревшими проектами. Фактически, они даже более распространены, чем разработка с нуля. Устаревшие проекты печально известны своим «качеством» кода, как производственного, так и тестового. Некоторые проекты могут вообще не иметь тестов. Как провести рефакторинг такого проекта?

Для безопасного рефакторинга у вас должны быть тесты, чтобы гарантировать, что ваш рефакторинг ничего не сломает. Но как внедрить тесты в проект с тесно связанным, не тестируемым кодом? Если бы код был хорошим и его можно было тестировать, вам не нужно было бы его рефакторить.

Это проблема курицы и яйца в старых проектах:
- Нужны тесты, чтобы убедиться, что рефакторинг прошёл успешно.
- Нужно провести рефакторинг кода, чтобы сделать его пригодным для тестирования.

Обойти эту проблему невозможно: тестовый и рабочий код неразрывно связаны; невозможно создать хорошие тесты, не вложив усилий в кодовую базу, которую они охватывают.

Чтобы преодолеть эту проблему, надо начать со сквозных и интеграционных тестов.

Сквозные тесты полностью имитируют конечного пользователя. Например, если ваше приложение представляет собой веб-сайт, сквозные тесты проверяют его через веб-интерфейс. Как правило, их мало, и они должны применяться только к наиболее важному функционалу: функциям, в которых вы никогда не хотите видеть каких-либо ошибок, и только если вы не можете получить такую ​​же степень защиты с помощью модульных или интеграционных тестов.

Большую часть работы обычно выполняют модульные тесты, потому что их дешевле писать и поддерживать. Однако в устаревшем проекте сквозные тесты являются единственным доступным вариантом, потому что это единственный тип тестов, который не требует изменений в коде (поскольку они взаимодействуют с приложением, используя тот же интерфейс, что и обычные пользователи). Сквозные тесты также обладают наибольшей устойчивостью к рефакторингу и не вызывают ложных срабатываний из-за ваших действий по рефакторингу.

В некоторых устаревших проектах также есть золотая середина, где вы можете писать интеграционные тесты вместо сквозных. Это проекты, которые имеют хотя бы некоторую степень разделения ответственности. Например, API с беспорядочным кодом, в котором всё же есть контроллеры. Вы можете протестировать эти контроллеры вместо полноценного вызова конечных точек API из отдельного процесса. Полученные тесты будут интеграционными, и их будет легче поддерживать, чем сквозные тесты.

Хорошая новость, что большое количество сквозных и интеграционных тестов — временные. Как только вы начнёте рефакторинг, замените сквозные тесты интеграционными, а интеграционные - модульными.

Итак, путь к рефакторингу устаревшего кода таков:
1. Определите небольшую связную область в приложении, которую можно было бы отрефакторить относительно быстро и без разрушения остального кода.
2. Покройте эту область сквозными или интеграционными тестами.
3. Выполняйте рефакторинг, разделив бизнес-логику и обязанности по оркестровке.
4. Покройте бизнес-логику юнит-тестами; оркестровку - интеграционными тестами.
5. Удалите сквозные тесты (если они не обеспечивают дополнительного тестового покрытия).
6. Помните, что адекватное покрытие модульными тестами невозможно без качественной кодовой базы.

Источник: https://khorikov.org/posts/2022-01-17-production-test-code-refactor/