Пошук · Мануфактура

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

Java · Основний курс · 43:10–49:58

Loadable Component і стабільні переходи

Для кожної сторінки створюється метод `isLoaded`, який очікує на характерний елемент через Selenide `shouldBe(Condition.visible)`. Цей підхід названо патерном Loadable Component. Перевірка завантаження має належати цільовій сторінці: `SignInPage` не повинен перевіряти внутрішні елементи наступної сторінки. Перехід можна додатково стабілізувати очікуванням, що елементи попередньої сторінки стали прихованими через `shouldBe(Condition.hidden)`. Таким чином тест підтверджує і зникнення попереднього стану, і завантаження наступного. Після вибору проєкту створюється окремий `ProjectPage`, назву якого виводять із URL та структури продукту.

Page Objects: рефакторинг тестів →

Java · Основний курс · 14:20–19:20

Спільний login і читабельні ланцюжки дій

Повторюваний login переноситься до `BaseTest`, після чого тест починається з уже відкритої сторінки проєктів. Запуск підтверджує успішну авторизацію, а консольний звіт показує пройдену перевірку `shouldBe(visible)` та її тривалість у мілісекундах. Коли fluent interface утворює довгий вираз, кожну логічну дію варто переносити на окремий рядок. Це не змінює виконання, але дозволяє читати сценарій зверху вниз і швидше співвідносити падіння зі звітом.

Selenide: iframe, fluent interface та конфігурація →

Java · Додаткові матеріали · 49:55–56:30

Умови та перевірки в Selenide

Очікуваний стан виражається через `shouldBe(...)` або `shouldHave(...)` і `Condition`, наприклад `visible` чи `text(...)`. Текстовий локатор створюється через `Selectors.byText(...)`, але пошук має стосуватися видимого DOM-тексту, а не вмісту `script` чи невидимих атрибутів. Static imports для Selenide, Selectors і Condition прибирають повторення назв class, зберігаючи читабельний DSL.

Створення першого Java-проєкту та тесту →

Java · Основний курс · 55:30–1:03:55

Основні параметри Selenide Configuration

`Configuration` містить багато параметрів, але для старту потрібні лише ті, що відповідають реальному середовищу. Assertion mode може дозволити soft assertions: окремі перевірки фіксують помилки, але тест доходить до кінця й лише тоді показує сукупний результат. `headless` приховує вікно браузера; у віддалених запусках такий режим є типовим. Розмір браузера радять ставити не довільно, а на мінімальну підтримувану продуктом ширину, бо саме там частіше проявляються проблеми компонування. Глобальний JavaScript click може трохи прискорити тести або обійти окрему проблему кліку, але його не слід вмикати всюди: він відрізняється від звичайної взаємодії й може зробити сценарій занадто швидким для застосунку. Для одиничного проблемного елемента краще обрати JavaScript лише в параметрах конкретного кліку. Швидке встановлення значення через JavaScript вставляє текст цілком. `sendKeys` або append потрібні, коли важливе посимвольне введення й виклик change/autocomplete-поведінки. Для завантажень Selenide має кілька режимів, а download folder варто розташувати в `build` для Gradle або `target` для Maven, щоб артефакти не потрапляли до репозиторію. `pollingInterval` визначає паузу між повторними перевірками умов на кшталт `shouldBe(visible)`; у прикладі стандартне значення — 200 мс. Зменшувати його слід лише після вимірювання: локально тест може прискоритися, але в Jenkins, BrowserStack або хмарних середовищах кожна перевірка має мережеву затримку між регіонами. Наприкінці викладач зводить мінімальну конфігурацію до `baseUrl` і обґрунтованого вибору headless-режиму.

Selenide: iframe, fluent interface та конфігурація →

Java · Основний курс · 1:10:00–1:16:56

Стабілізація перевірок і підготовка коду до коміту

Перед статичним читанням тексту додається очікування видимості елемента, щоб уникнути перевірки ще не завантаженого стану. Page Object може містити очікування того, що користувач бачить на сторінці, тоді як тест зберігає бізнес-порівняння отриманого значення. Після рефакторингу сценарій читається як послідовність дій через `SignInPage`, `ProjectsPage` і `ProjectPage`, а реалізація рознесена між відповідними класами. Наприкінці показано `Reformat Code` та `Optimize Imports`: IDE прибирає зайві імпорти й упорядковує статичні та нестатичні поля й методи. Автоматичне форматування перед комітом не замінює запуск тестів, бо зміна порядку ініціалізації може зламати код. Звичка — очистити імпорти, відформатувати код і перевірити його до коміту.

Page Objects: рефакторинг тестів →

Запитати в чаті про «shouldBe» →