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