Диагностика падений и запуск в CI

Падение — начало расследования

Сохраните исходное расхождение до любой правки ожиданий. Красный тест сообщает о расхождении наблюдения и ожидания, а не автоматически доказывает дефект продукта. Возможно, правило изменилось, исходные данные неверны, ожидание хрупкое или среда не готова. Начните с названия сценария, первого assertion, actual и expected. Повторите точную команду на том же снимке. Не удаляйте assertion и не расширяйте допустимые ответы до любого значения ради зелёного отчёта.

В buggy-версии AUTO-CORE-1 есть три целевых изменения: подсчёт title через UTF-16 length, разрешение читать чужой draft и пропуск проверки публикационного разрешения. Один и тот же contract.test.mjs даёт четыре отказа. Два сценария замечают одну проблему чтения: прямой тест чужого draft и предпосылка сценария редактора. Поэтому четыре красных теста не означают четыре независимых дефекта. Счётчик тестов и число причин — разные метрики.

Что сохранять в доказательствах

Для каждого отказа зафиксируйте версию договора, реализацию fixed/buggy, версию Node, команду и первую разницу. Например, в Unicode-тесте actual=false,expected=true показывает неверную единицу длины. В тесте чтения actual200 против expected404 показывает нарушение A4. В тесте Boris/t1 возвращается published200 вместо FORBIDDEN403: нужно проверить A5 и полный эффект, а не переименовать ожидание в успех.

В diagnostics.test.mjs один зелёный тест проверяет, что assertion действительно бросает AssertionError на заведомо неверном числе. Это диагностика механизма проверки, а не дополнительное покрытие бизнеса. Не складывайте её с бизнес-сценариями как доказательство полноты требований. Аналогично строка «20 tests» полезна для контроля неизменённости пакета, но ничего не говорит о пропущенных границах description или настоящей авторизации: таких интеграций здесь нет.

CI повторяет команду, а не создаёт качество

В отдельном учебном репозитории установите поддерживаемый Node, сохраните все .mjs рядом и запускайте node --test contract.test.mjs diagnostics.test.mjs. Основной набор не имеет внешних зависимостей, поэтому npm install для него не требуется. CI должен сохранить stdout/stderr и код завершения. Если добавить «|| true», красный набор перестанет блокировать ошибку; зелёный статус задачи тогда не отражает результат тестов.

Намеренно красный прогон держите отдельной командой или отдельной диагностической задачей с явной проверкой ожидаемого exit 1. Не включайте buggy в основной обязательный зелёный job без объяснения. Случайный запуск node --test по папке использует fixed по умолчанию; launcher run-buggy.mjs сам по себе не является test-файлом. Если переменная ORBITDESK_VARIANT осталась в окружении, очистите её перед основным прогоном или явно задайте fixed.

Для браузерного сбоя trace помогает посмотреть последовательность действий, DOM и сетевые события, когда такой запуск реально был. Он может содержать чувствительные данные, поэтому учебная фикстура остаётся синтетической. В этом курсе trace не создан, поскольку Playwright runner не исполнялся. Ретраи могут помочь наблюдать нестабильность, но повторный зелёный результат не стирает первый отказ. Сначала сохраните доказательства и найдите зависимость от состояния, ожидания или среды.