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

Java · Основний курс · 30:00–39:02

Рефакторинг сторінки зі списком проєктів

Сторінка після авторизації отримує назву `ProjectsPage`, бо вона містить список, пошук і вибір проєктів. Її `open` викликає Selenide явно: випадковий виклик однойменного методу самого класу створив би рекурсію та завершився `StackOverflowError`. IntelliJ IDEA підказує кваліфікувати виклик через `Selenide`. Методи відкриття, пошуку та вибору проєкту переносяться в `ProjectsPage`, а тест зберігає один інстанс цього класу. Викладач розрізняє declaration змінної та initialization об'єкта, використовує автодоповнення і після кожного кроку повторно запускає тест. Для базового URL попереджається про ризик випадкових подвійних слешів.

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

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

Page Objects для README і вибір локаторів

Сценарій розділяється між `ProjectsPage`, сторінкою окремого проєкту та `ReadmePage`. Для переходів використовуються посилання README й кнопка Edit; якщо немає стабільнішого атрибута, елемент у демонстрації шукається за видимим текстом. Текстовий локатор прийнятний для продукту з однією стабільною мовою, але стає крихким, коли копірайт часто змінюється або UI має кілька локалізацій. Після перемикання мови такі тести масово падають. Автоматизацію повної перевірки локалізацій викладач не рекомендує як першу задачу для початківця: спершу потрібно зрозуміти DOM і стабільні контракти конкретного продукту.

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

Java · Основний курс · 40:28–51:04

Assertions і побудова Page Object

Замість довгого `locator.waitFor` для очікуваного стану використовується динамічний Playwright assertion на `Locator`, наприклад перевірка видимості або тексту. Так очікування і причина падіння залишаються частиною перевірки, а не окремим технічним кроком. Для `HomePage`, `SignInPage`, `ProjectsPage` і сторінки окремого проєкту створюються Page Object-и. Кожен отримує спільний `Page` через constructor, зберігає дії на своїй сторінці та повертає наступний Page Object там, де сценарій переходить далі. Початковий лінійний тест рефакториться у послідовність доменних дій: відкрити home page, увійти, знайти проєкт, відкрити його й перевірити title. Це прибирає locator-и з тесту та залишає у ньому читабельний користувацький сценарій.

Playwright для Java: основи та поглиблення →

Java · Основний курс · 49:58–1:01:50

`ProjectPage`, діагностика падіння та коректна відповідальність

Назва `ProjectPage` обирається після аналізу URL, HTML і функцій сторінки: вона охоплює не лише тест-кейси, а й налаштування, шаблони та користувачів проєкту. Методи `isLoaded` у `ProjectsPage` і `ProjectPage` роблять public, щоб тест міг явно перевіряти кожний перехід. Під час запуску тест падає через неперевірений селектор. Викладач знаходить перший релевантний рядок власного коду у stack trace, звіряє DOM і переносить перевірку повідомлення про успішний вхід до відповідальнішого місця. Характерний пошуковий елемент зберігається в полі Page Object і повторно використовується для перевірки завантаження, після чого тест знову проходить.

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

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

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

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

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

Java · Основний курс · 1:16:02–1:25:30

Application facade і потокобезпечна ініціалізація

Щоб не створювати Page Object-и безпосередньо в кожному тесті, будується невеликий application facade. Він один раз приймає `Page`, створює `HomePage`, `SignInPage`, `ProjectsPage` та інші сторінки у правильному порядку й віддає їх тесту через короткі методи. Під час рефакторингу перевіряється момент ініціалізації: Page Object-и не можна створювати раніше, ніж JUnit integration надасть валідний `Page`. Після перенесення створення у constructor application object отримується стабільний lifecycle без повторюваних `new ...Page(page)` у тесті. У вбудованій Playwright JUnit implementation показано зберігання instances через `ThreadLocal`. Це дає окремі Playwright, Browser, BrowserContext і Page для кожного test thread; tracing lifecycle додатково враховує завершення, падіння або скасування тесту.

Playwright для Java: основи та поглиблення →
Запитати в чаті про «ProjectsPage» →