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