Проверка результата Codex: тесты, типы, lint и сборка

Краткий ответ

Сгенерированный код становится готовым изменением только после проверки. Codex должен не просто запустить привычный набор команд, а связать каждую проверку с риском задачи: корректностью логики, контрактом типов, качеством сборки и реальным поведением пользователя.

Пирамида доказательств

Начинайте с быстрого и узкого сигнала:

1. воспроизвести дефект или получить падающий тест; 2. запустить целевой тест после изменения; 3. проверить типы и lint затронутого пакета; 4. выполнить более широкий набор unit или integration-тестов; 5. собрать production-версию; 6. проверить пользовательский сценарий в подходящей среде.

Такой порядок сокращает время обратной связи. Полный прогон первым шагом может долго падать из-за уже известной локальной причины, а один unit-тест в конце не обнаружит проблему сборщика.

Регрессионный тест должен ловить старый баг

Хороший тест:

воспроизводит наблюдаемое условие;
падает на старом поведении;
проверяет результат, а не внутреннюю реализацию;
включает важную отрицательную ветку;
не зависит от случайного времени и порядка.

Например, при гонке гостевого и авторизованного запросов недостаточно проверить один успешный ответ. Нужен сценарий, где старый гостевой ответ приходит позже и не перезаписывает актуальное состояние.

Typecheck, lint и build отвечают на разные вопросы

Typecheck проверяет согласованность статических контрактов, но не выполняет бизнес-логику. Lint находит запрещённые или подозрительные конструкции и несогласованный стиль, но не доказывает корректность ответа API. Build проверяет цепочку компиляции, bundling и prerender, но успешная сборка может содержать функциональный дефект.

Поэтому отчёт «build зелёный» не заменяет тест. С другой стороны, тест, запущенный через runtime-транспиляцию, может пройти при ошибке отдельного production tsconfig.

Проверяйте пользовательскую границу

Для API это статус, схема ответа, права доступа и побочные эффекты в данных. Для UI — загрузка, пустое состояние, ошибка, успех и адаптивный вид. Для миграции — первый и повторный запуск, старые записи и частично мигрированное состояние.

Пример матрицы:

Изменение Автоматическая проверка Ручная проверка

защита route guard/e2e test прямой переход гостем

форма component test ввод и submit в браузере

миграция integration + idempotency dry run на копии

SEO heading DOM assertion prerendered HTML и live DOM

Ручная проверка должна иметь конкретные шаги и ожидаемый результат, а не «посмотрел — вроде нормально».

Честный отчёт о проверке

В финале Codex должен перечислить:

точные команды;
количество или область прошедших тестов;
проверки, которые не удалось запустить;
причину ограничения;
оставшийся риск;
ручной сценарий и его результат.

Нельзя говорить «всё проверено», если команда завершилась по timeout, вывод был обрезан до статуса или браузерный сценарий не открывался.

Упражнение: карта риска

Для изменения авторизации составьте четыре столбца:

1. риск; 2. тест, который его ловит; 3. команда запуска; 4. ожидаемый сигнал падения.

Обязательно включите: неверные данные, истёкшую сессию, отсутствие согласия, повторный запрос и доступ гостя. Затем попросите Codex реализовать только недостающие проверки, не меняя production-код.

Частые вопросы

Нужно ли всегда запускать весь test suite?

Для локальной правки сначала достаточно целевых тестов. Перед завершением рискованного или широко используемого изменения нужен пропорционально широкий прогон. Если полный suite слишком дорог, зафиксируйте непроверенную область.

Можно ли доверять тесту, написанному тем же агентом?

Тест — доказательство только если он действительно различает старое и новое поведение. Просмотрите assertions, при возможности подтвердите падение на старой реализации и добавьте проверку на ложноположительный сценарий.

Что делать с уже падающими несвязанными тестами?

Отделить существующее падение от нового: воспроизвести его до правки или на неизменённой области, задокументировать точный тест и продолжить только если это не мешает доказать текущий результат. Не исправлять соседнюю проблему без согласования.

Что важно запомнить

Проверки выбираются по рискам, а не по привычному списку команд.
Регрессионный тест должен отличать старый дефект от исправленного поведения.
Typecheck, lint, build и пользовательский сценарий дополняют друг друга.
Итоговый отчёт обязан честно называть непроверенные области.

https://yadro-code.ru/lessons/without-university/codex-agent-workflows/codex-agent-09