У долгоживущего сервиса почти всегда два контракта: тот, что команда описала в тестах, и тот, которым уже пользуются клиенты. Характеризационные тесты предлагают защищать второй — фиксировать не ожидаемое, а фактическое поведение системы до изменений. Для российских команд с легаси, интеграциями и активными рефакторингами это способ узнать о несовместимости в pull request, а не из ночного инцидента.
Об этом пишет Stack Overflow Blog. Обычные регрессионные тесты обычно появляются вместе с новой функцией: разработчик проверяет, что метод возвращает нужный результат, а API отвергает некорректный запрос. Через несколько лет эксплуатации вокруг такого кода вырастает слой неявных правил: порядок элементов в ответе, формат ошибки, значение поля по умолчанию, отсутствие свойства вместо null. Их никто не утверждал как контракт, но кто-то вполне мог встроить в свою интеграцию.
Эту проблему хорошо объясняет закон Хайрама Райта: при достаточном числе пользователей API зависимость возникает почти от любого наблюдаемого свойства интерфейса, а не только от документации. Команда может исправить очевидную ошибку и тут же получить жалобу от клиента, для которого именно эта «ошибка» была частью рабочего сценария. Формально код стал лучше; практически — сломал чужой процесс.
Термин characterization tests, или характеризационные тесты, популяризировал Майкл Физерс в книге Working Effectively with Legacy Code. Принцип намеренно простой: перед доработкой непонятного участка кода нужно прогнать его на выбранных входных данных и закрепить текущий результат. Даже если результат похож на баг. Такой тест не объявляет поведение правильным — он требует, чтобы его изменение было осознанным решением команды.
Разница с привычным подходом не косметическая. Обычный тест говорит: «система должна вести себя так». Характеризационный — «система сейчас ведёт себя так; объясните, почему это меняется». Это особенно полезно там, где исходные требования потеряны, авторы решения давно ушли, а бизнес-процесс продолжает опираться на старую реализацию.
Писать такие проверки вручную утомительно. Для сложной функции нужно подобрать множество входов и аккуратно описать каждый выход; для сервиса — учесть эндпоинты, пограничные случаи, обращения к базе, очередям и внешним API. Поэтому близкие идеи давно используют в golden master и approval testing: эталонный результат сохраняют целиком, а следующие запуски сравнивают с ним. Снимки интерфейсов во фронтенде работают по тому же принципу, хотя их ценность быстро падает, если команда без чтения обновляет любой большой diff.
Для сервисов, по версии автора публикации, наиболее полезным источником эталонов становится боевой трафик. Запись входящих запросов и ответов превращает реальные пользовательские сценарии в набор воспроизводимых проверок — в том числе с данными, которые никто не придумал бы в тест-кейсе. Если одновременно записывать обращения к зависимостям, можно зафиксировать и побочные эффекты: SQL-запросы, вызовы других сервисов, сообщения в очередях. При повторном запуске зависимости отвечают из того же набора записей, а изменение видно как diff.
Это закрывает класс дорогих регрессий, который часто проходит мимо функциональных тестов. HTTP-ответ может остаться прежним, но новый релиз внезапно делает лишний запрос к базе на каждый вызов или иначе обращается к downstream-сервису. На тестовом стенде разница незаметна, под нагрузкой — превращается в задержки, рост стоимости инфраструктуры или каскадные ошибки. Проверка реального поведения помогает заметить и такие сдвиги.
У подхода есть цена. Записи нужно очищать от динамических значений: временных меток, сгенерированных идентификаторов, токенов и прочего шума. Но слишком широкие исключения обесценят проверку: если игнорировать половину ответа, тест перестаёт быть страховочной сеткой. Полезнее исключать конкретные поля и отдельно решать вопросы с персональными данными, секретами и доступом к записям боевого трафика.
Наибольший эффект характеризационные тесты дают перед рефакторингом легаси, обновлением фреймворка или ORM, а также при переписывании сервиса на другом языке или архитектуре. Старый сервис в этом случае становится исполняемой спецификацией: одинаковые запросы отправляют в обе версии и разбирают каждое отличие. Это также неплохая защита при крупных изменениях с участием ИИ: если помощник одновременно переписал код и обновил обычные тесты, независимый снимок прежнего поведения остаётся одним из немногих проверяемых ориентиров.
Красный результат здесь не равен багу: он означает, что система изменила поведение. Иногда этого и добивались — тогда команда обновляет эталон и заранее предупреждает потребителей. Иногда нет — и регрессия найдена до релиза. Чем больше сервис живёт в продакшене, тем важнее вопрос не «что мы планировали пять лет назад», а «какие обещания код уже успел раздать своим пользователям».