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