Відеобібліотека

Знайди точне пояснення

Пошук у нотатках курсу Design Patterns для автоматизаторів з переходом на потрібну секунду.

Python мануфактураJavaDesign Patterns для автоматизаторів

Design Patterns для автоматизаторів · 20:45–36:16

Page Object для сторінок і компонентів

Page Object визначається як опис поведінки логічної частини сторінки. Такою частиною може бути ціла сторінка, popup, header, footer, фільтр або картка товару; поділ на pages і components є організаційним уточненням цього самого підходу. Прямий тест послідовно розкладається на `HomePage`, `SearchResultPage`, `ProductPage` і `CartPage`. У кожен клас переносяться лише дії та перевірки його UI-контексту: пошук, відкриття товару, додавання до кошика, відкриття кошика та підтвердження завантаження. Після перенесення тест читається як послідовність бізнес-дій, але реальний запуск усе одно потрібен, бо помилка в регістрі назви товару вже спричинила падіння.

1. Патерни проєктування для UI тестів (перезапис) →

Design Patterns для автоматизаторів · 1:33:02–1:40:00

Simulators, real devices і mobile farms

Чим більше застосунок використовує стандартні components, тим більше smoke/feature checks можна виконати на simulator/emulator, залишивши фінальну перевірку на реальних пристроях. Custom animation, vendor-specific behavior і складні native components підвищують цінність physical devices. Паралельний запуск на реальних девайсах потребує mobile farm; BrowserStack і Sauce Labs надають готову інфраструктуру, а велика продуктова команда може побудувати власну. Незалежно від інструмента, короткий suite має запускатися локально, а масштабна ферма виправдана лише достатнім mobile traffic і складністю продукту.

Мобільне тестування та автоматизація →

Design Patterns для автоматизаторів · 15:08–23:22

WebView, rendering і accessibility

WebView може мати доступ до native navigation, Bluetooth, secure storage та інших можливостей через інтеграційний шар. Водночас Flutter/React Native rendering і custom components створюють окремі ризики для accessibility та поведінки на різних пристроях. Найпростіша практична accessibility-перевірка — збільшити системний font size й переконатися, що текст не виходить за кнопки, поля та контейнери, а елементи залишаються клікабельними. Також згадуються contrast, tactile feedback і безпечна animation, але детальний аудит цих стандартів винесено за межі відео.

Мобільне тестування та автоматизація →

Design Patterns для автоматизаторів · 45:50–58:36

Device analytics і перемикання оточень

Device matrix слід будувати за production analytics: OS versions, vendor/model, screen resolution, update rate та частка foldable devices. Ще корисніше зіставити ці дані з користувачами, які приносять основний revenue, щоб бюджет на реальні пристрої відповідав бізнес-ризику. Стандартні platform components зменшують ризик, але Samsung, Huawei та інші vendors можуть мати власні UI/OS особливості й різну доступність Google services. Для dev build варто додати простий environment switcher між dev, QA, stage і production endpoints, а logs збирати через Xcode/Android Studio.

Мобільне тестування та автоматизація →

Design Patterns для автоматизаторів · 1:23:41–1:33:02

Scroll, virtualized lists і locator contracts

Mobile list часто рендерить лише елементи, видимі на screen, тому до п'ятого чи наступного item неможливо звернутися без scroll. Це відрізняється від звичайного HTML, де весь отриманий DOM часто вже доступний driver. Для пошуку радять `accessibilityId`, accessibility label, Android resource ID або content description, а не XPath. Тестувальник може сам додавати ці атрибути в application code і надсилати невеликий PR на review, бо hotfixes та custom components регулярно порушують навіть узгоджений locator guideline.

Мобільне тестування та автоматизація →

Design Patterns для автоматизаторів · 1:29:05–1:40:50

Loadable Component проти flaky UI-тестів

Після кожної дії потрібно підтверджувати її наслідок на поточній сторінці, а перед роботою з новою сторінкою чи компонентою — чекати, що вони готові. Це важливо для асинхронного UI: картка може вже відображатися, але stock або delivery methods ще завантажуються, тому ранній клік `addToCart` не дасть очікуваного результату. Спільний інтерфейс `Loadable` з методом `isLoaded` робить цю вимогу явною для pages і components без великого base class. `isLoaded` може містити кілька очікувань: видимість title, image, кнопки й залежних даних. Автор дозволяє такі очікування в Page Object, бо вони визначають готовність системи до наступної дії, і пропонує перевіряти на code review, що новий компонент реалізує контракт завантаження.

1. Патерни проєктування для UI тестів (перезапис) →

Design Patterns для автоматизаторів · 2:00:00–2:20:00

TypeScript API-приклад і role-specific UI

У TypeScript-прикладі factory method створює registration DTO з random data, Controller приймає DTO, Axios config зберігає базові settings, а response decorator порівнює фактичний JSON з типізованою model. Якщо поле відсутнє, custom error підказує class і type, які потрібно оновити. Для продукту з різними clients, roles і permissions UI-перевірки краще групувати невеликими components або role-specific classes. Менші класи полегшують code review і зменшують merge conflicts, але надмірне дроблення так само небажане; shared page behavior залишається спільним.

2. API. Патерни проєктування або чому огірок нікому не тре. →
Запитати в чаті про «components» →