Короткий ответ Сначала стоит покрыть существующее поведение модуля характеризационными тестами (characterization tests), фиксирующими текущее поведение как есть, а уже затем вносить изменения — это даёт сеть безопасности и подтверждает, что ничего непредвиденное не сломалось. Как это работает подробнее Характеризационный тест не проверяет «правильность» поведения в абстрактном смысле — он фиксирует, что модуль делает прямо сейчас, на реальных или приближенных к реальным входных данных. Если после правки такой тест ломается, это сигнал, что поведение изменилось, и нужно осознанно решить, ожидаемо ли это, вместо того чтобы узнавать об этом от пользователей в продакшене. Пример кода Что использовать на практике Практика. Для изменений стоит выбрать минимально инвазивный подход: сначала добавить тесты вокруг кода, который планируется менять (не переписывая его), затем вносить изменения маленькими шагами, перезапуская тесты после каждого шага. Если модуль имеет побочные эффекты (запись в БД, сетевые вызовы), для т
Загрузка…
