Відеобібліотека
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Поточна Android guidance окремо перелічує Espresso, UI Automator і Compose Test як instrumented UI testing APIs; конкретний seam потрібно обрати за UI surface та scope тесту.
Типи мобільних застосунків та мобільна автоматизація →Apple UI automation framework, інтегрований із XCTest, що взаємодіє із застосунком через accessibility information і дозволяє знаходити UI elements, виконувати actions та перевіряти state.
Типи мобільних застосунків та мобільна автоматизація →Current Android guidance перелічує Espresso, UI Automator і Compose Test як окремі instrumented testing APIs. Це уточнює перелік інструментів із відео, але не встановлює універсальне mapping без аналізу конкретного UI.
Типи мобільних застосунків та мобільна автоматизація →Open-source ecosystem для UI automation, у якому client надсилає WebDriver-compatible commands до Appium server, а platform driver виконує їх на конкретній automation technology.
Типи мобільних застосунків та мобільна автоматизація →Дає офіційну точку входу до native Android UI tests і synchronization model.
Типи мобільних застосунків та мобільна автоматизація → Першоджерело ↗Design pattern, який відділяє test code від page-specific locators і operations; UI change зазвичай локалізується в одному object.
Неймінг та структура automation-проєкту →Middle має володіти мовою настільки, щоб писати й підтримувати UI та API tests, а також пояснити, як перевірити нову поведінку й які наявні тести варто змінити. UI automation легше показує зв'язок із діями користувача, тоді як API automation часто швидша й стабільніша, але вимагає впевнено працювати з більшими структурами даних і контрактами. Очікується знання базових типів, перетворень і наслідків звуження/розширення типів, dependency/build tool свого stack (`requirements.txt`, `pip`/`uv`, Maven/Gradle, npm), а також можливостей test runner. Важливо вміти запустити тести паралельно й розуміти, які ресурси та змінні створюються для кожного worker.
UI-тест на початку наочніший: відкрити сторінку, знайти елемент, натиснути й побачити результат. Такий сценарій дає швидший практичний зворотний зв’язок людині, яка ще не звикла до IDE, коду, бібліотек і діагностики помилок. Навчальний маршрут іде від сирого сценарію до повторно використовуваних функцій і патернів проєктування, а вже потім — до оптимізації через API. Так учасник розуміє, що саме він спрощує і чому нижчий рівень може бути швидшим та стабільнішим. Postman корисний для дослідження API, але в межах цієї дискусії не вважається повноцінною заміною кодової автоматизації: складніше структурувати великі набори тестів, повторно використовувати частини сценарію й контролювати архітектуру. Для системного навчання автор обирає код та IDE.
На системному рівні перевіряється вже розгорнута система. Тут корисно розділяти UI-сценарії користувача й перевірки системних компонентів або API, що формують дані для інтерфейсу. На багатьох реальних проєктах нижні рівні покриті нерівномірно або майже відсутні. Тому QA не може просто виходити з ідеальної піраміди: потрібен шар перевірок, який дає впевненість у поведінці всієї системи на тестовому оточенні.
Учасники спочатку вчаться складати й запускати тестовий сценарій. Після цього курс поступово пояснює, як працюють типи даних, операції зі строками, повторне використання коду та інші конструкції, які вже зустрілися в реальній роботі. Саме з цього підходу виникає питання: якщо класична піраміда тестування радить мати більше нижньорівневих тестів, чому курс починається з UI, а не з API.
До проєкту додається актуальна RestAssured dependency. Практичний сценарій складається з логіну, отримання проєкту і створення test suite, який пізніше можна використати як API precondition для UI-тесу. Якщо UI- та API-теси живуть в одному проєкті, їх варто рознести за packages `web` і `api`. Перший API-тест створюється як окремий Java class і спочатку збирає весь flow в одному місці.
Знайдені плитки проєктів зберігаються у змінній типу `ElementsCollection` — власному типі Selenide, пристосованому до роботи з набором UI-елементів. Поруч автор порівнює масиви з `List` і `Set`: колекції мають готові операції для обходу, фільтрації, пошуку, сортування, додавання та очищення. Масив може бути трохи компактнішим або швидшим, але для UI-автотесту ця різниця зазвичай губиться на тлі звернень до браузера. Читання значення з пам’яті триває незрівнянно менше, ніж отримання тексту зі сторінки локально, у Jenkins або через BrowserStack. Тому для звичайних тестів важливіші зручність і читабельність; мікрооптимізації мають сенс лише після вимірювання реальної проблеми, наприклад коли підготовчі дії спотворюють performance test. Для розміру масиву використовується `length`, а для колекції — метод `size()`. IDE підказує доступні операції та може запропонувати stream, але на цьому етапі урок радить залишатися з простішими колекційними API.
[Дивитися з 05:30](https://www.youtube.com/watch?v=viR9Rnmxse4&t=330s). Suite ускладнюється вертикально: спочатку прямий UI-flow, потім reusable helpers, Page Objects, розширення object model, API preconditions і повторне використання authenticated state. Складніший сценарій може створити другу людину, зареєструвати її на event і перевірити participant list від імені admin. Пізніше ті самі tests мають запускатися в CI, де з’являться окремі environment-specific failures.
Runner клонує репозиторій, встановлює або використовує залежності та запускає тестовий процес. UI-тести додатково піднімають один чи кілька браузерів; навіть headless browser споживає відчутну кількість RAM. Розмір runner слід визначати за реальною паралельністю, наборами браузерів і піковим споживанням, а не за вимогами звичайного application build.
У React Native частина компонентів доступна як native UI, частина може поводитися як web content, а для platform-specific можливостей додається Swift або Kotlin code. Крім Appium, для такого стеку згадується Detox. Якщо продукт значною мірою рендериться як web view, більшу частину логіки іноді дешевше перевіряти Playwright-тестами на web-рівні, залишивши кілька справжніх mobile flows для інсталяції, permissions і наскрізної інтеграції. Flutter сам рендерить значну частину UI, тому accessibility tree і поведінка елементів можуть відрізнятися від стандартних native components. Це не робить Flutter автоматично добрим чи поганим: потрібен окремий proof of concept на реальному застосунку, перш ніж обирати automation stack.
ORM є компромісом: прискорює типову розробку, але може генерувати неефективні queries або приховувати N+1, зайві joins і transaction behavior. Повертатися до ручного SQL слід за профілем і вимірюванням, а не через загальну недовіру до abstraction. У бажаній архітектурі backend виконує бізнес-перетворення, а frontend переважно відображає готовий contract. Якщо значна logic усе ж живе на frontend, це підсилює цінність UI/component automation. Коли продукт створюється з нуля й UI ще немає, логічно почати з API. Для наявного продукту без automation перший seam вибирають за ризиком і вартістю ручної регресії, а не за універсальним правилом «завжди UI» або «завжди backend».