Старый расчет скидок трудно читать, а документация противоречива. Переписывать его по впечатлению рискованно: странная ветка может отражать действующее правило. Перед рефакторингом полезно зафиксировать наблюдаемое поведение на осмысленных случаях и отдельно согласовать найденные дефекты.
Что подготовить
- Публичные входы и выходы модуля, вызывающий код и существующие проверки.
- Обезличенные примеры обычных заказов и крайних комбинаций условий.
- Перечень известных ошибок и решения о том, сохранять ли их временно ради совместимости.
Порядок работы
- Найдите устойчивую границу вызова и создайте тестовый адаптер без изменения внутренней логики.
- Составьте классы входов: отсутствие скидки, порог, пересечение правил, отмена и пустой заказ.
- Запишите текущие результаты, затем проверьте их смысл с владельцем правил. Не называйте автоматически полученный результат правильным.
- Изолируйте время, внешние справочники и случайные значения, чтобы повторный запуск давал сопоставимый результат.
- Рефакторьте небольшими шагами, сравнивая выходы и побочные эффекты. Исправление поведения оформляйте отдельным изменением с новым ожидаемым результатом.
Разобранный пример
При сумме ровно 10000 действует скидка, а при 9999,99 — нет. Отдельный случай содержит купон и категорийную скидку: старый код применяет их последовательно. Эти примеры защищают пороги и порядок, но не требуют сохранять вложенность условных операторов.
Как проверить результат
- Покрыты границы условий, а не только несколько типичных заказов.
- Проверки сравнивают значимые результаты, не привязываясь к именам внутренних методов.
- Сохранены правила округления, порядок применения скидок и изменения связанных записей.
Если что-то пошло не так
Если тесты фиксируют очевидную ошибку, пометьте ее как известное поведение и согласуйте отдельное исправление. Когда модуль невозможно изолировать, начните с более широкой границы и постепенно вводите управляемые зависимости.
Промпт для разбора ваших материалов
Изучи модуль и примеры входов. Предложи характеристические тесты на публичной границе, выдели неоднозначные правила и известные дефекты. Составь последовательность небольших рефакторингов, сохраняющих проверяемое поведение, без одновременной смены требований.Частые вопросы
Нужно ли стопроцентное покрытие строк?
Сам процент не гарантирует защиты поведения. Приоритет имеют значимые ветви, границы и последствия операций.
Можно ли просто сохранить снимки всех ответов?
Снимки полезны, если исключен шум и понятен смысл изменений. Огромный непроверяемый снимок легко обновить вместе с ошибкой.
Материал библиотеки решений Ильи Тарасова / TarasovWeb.
Как выбрать защитные примеры для старого модуля
Начните с публичных входов и наблюдаемых выходов. Если модуль рассчитывает итог заказа, сохраните примеры без скидки, со скидкой, с несколькими позициями, пустым набором и пограничными значениями округления. Не переносите во внешний контракт каждую внутреннюю функцию: цель проверки — сохранить нужное поведение при изменении устройства кода.
Разделите обнаруженные особенности на подтверждённые требования, известные дефекты и поведение, смысл которого пока неясен. Для последней группы полезен характеризующий тест: он фиксирует текущий результат, но не объявляет его правильным навсегда. Перед изменением такого результата требуется отдельное решение, а не случайное обновление ожидаемого значения.
Добавьте один тест, который связывает вход и выход через свойство. Например, перестановка независимых позиций не должна менять итог, если правила расчёта не зависят от порядка. Это предложение необходимо подтвердить предметной логикой: некоторые скидки действительно могут применяться последовательно. Проверка свойства дополняет конкретные примеры и помогает найти случаи вне маленькой таблицы.
Во время рефакторинга меняйте структуру небольшими шагами и проверяйте, какая граница поведения затронута. Если одновременно исправлять ошибку и переписывать алгоритм, причину расхождения будет сложнее установить. Сохраните воспроизводимые входы для каждой найденной регрессии. В итоговом отчёте объясните, какие риски покрыты, а какие требуют проверки интеграции или реальных объёмов данных.
О проекте
Практическая библиотека Ильи Тарасова и TarasovWeb. Telegram-канал · Личная страница · ВКонтакте.
#tarasovweb #ИльяТарасов