KIZZ ENGINEERING NOTE
Какие тесты нужны продукту, который меняют AI-агенты
AI увеличивает объём возможных изменений. Значит, тестовая система должна быстрее отвечать на главный вопрос: какое бизнес-правило могло сломаться именно здесь?
- Автор
- KIZZ Engineering · product engineering
- Опубликовано / обновлено
- 21 августа 2026 / 21 августа 2026
- Время чтения
- 6–8 минут
Coverage не равен уверенности
Высокий процент покрытия может защищать простые getters и пропускать двойное списание, неверный переход заказа или недоступный CTA на мобильном устройстве.
Мы начинаем со стоимости ошибки и изменяемости правила, а затем выбираем самый дешёвый уровень проверки, который действительно обнаружит нарушение.
Минимальный защитный контур
Для большинства сложных web-продуктов нужны несколько дополняющих уровней.
- — Unit/property tests для расчётов, policy и чистых бизнес-правил.
- — Contract tests для API, providers, billing и сериализации состояния.
- — State-machine tests для заказов, jobs, retries и reconciliation.
- — Browser proof для критических пользовательских и операторских сценариев.
- — Telemetry и alerts для фактов, которые невозможно полностью доказать до production.
Агент должен понимать критерий завершения
Проверки становятся частью задачи, а не отдельной фазой после генерации. Агент получает список рисков, авторитетные контракты и команды, которые должен пройти результат.
Это снижает стоимость review: человек оценивает решение и остаточный риск, а не вручную восстанавливает базовую корректность каждого изменения.