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

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

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

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

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

Auth state і controller context

Token можна зберігати у змінній test class, fixture/context або окремому state object; вибір залежить від lifecycle test runner і потрібної ізоляції. API authorization допустимо перевіряти багато разів, на відміну від дорогого UI-login у кожному тесті. Controller може зберігати token як context і автоматично додавати header до calls. Порожній token дає змогу тим самим controller перевірити unauthorized flow. Controllers одного domain можна об'єднати facade-подібним entry point, якщо це справді скорочує тест.

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

Design Patterns для автоматизаторів · 1:07:10–1:20:11

State для вибраного товару та локальний selector scope

`ProductInfoDto` передається в конструктор `ProductItem` один раз і стає станом компонента. Методи `hasTitle`, `addToCart` та `openProductPage` використовують той самий товар без повторення аргумента в кожному виклику. Це корисно, коли багато методів одного класу працюють з одними й тими самими даними. `ProductList` надає фабричний метод, який створює `ProductItem` для потрібного товару. Всередині компонента спільний батьківський selector картки формується один раз з `id`, а конкретні методи звужують пошук до title чи кнопки. Так selector scope і стан залишаються локальними для картки, а тест не знає її DOM-структури.

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

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

Auto-waiting і `slowMo`

Playwright перед дією автоматично перевіряє набір actionability conditions, а не обмежується document ready state. Це краще відповідає React/Angular interfaces, де сторінка формально завантажена раніше за dynamic content. Нульовий `slowMo` може виявитися занадто агресивним для application з race conditions, помилками promises або некоректними callbacks. Невелика затримка стабілізує flow, але такі падіння також корисно розглядати як можливі defects application, а не автоматично приховувати великим timeout.

Playwright Java, пишемо тести та робимо Selenide на мінімалках →

Design Patterns для автоматизаторів · 27:30–37:30

Message queues, adapters і перевірка authorization

Kafka, RabbitMQ або Amazon SQS можуть передавати events чи тимчасовий state між services. Один service також може мати різні adapters для REST, gRPC, WebSocket, GraphQL, database або message broker, тому тестова структура групується за реальним resource/transport contract. На gateway інколи помилково перевіряють лише наявність `Authorization` і prefix `Bearer`. Для кожного endpoint корисна негативна перевірка з відсутнім або випадковим token: вона одночасно виявляє слабку authorization, неправильний route і проблеми service registration.

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

Design Patterns для автоматизаторів · 1:30:00–1:37:00

Collections і BrowserContext

Перебирання UI element collection створює багато browser round trips для visibility і text. Коли можливо, краще працювати з конкретним target element або один раз отримати потрібний text/content і перевірити його локально; selectors за `nth`/index названі нестабільними. `BrowserContext` ізолює cookies, local/session/shared storage, base URL та device emulation settings. Окремий context на test дає дешевшу ізоляцію, а Playwright через Page/Frame API працює з tabs, iframes і dialogs без Selenium-style global driver state.

Playwright Java, пишемо тести та робимо Selenide на мінімалках →

Design Patterns для автоматизаторів · 1:35:00–1:45:00

ORM entities і перетворення data layers

Hibernate або Entity Framework можуть mapити database rows у `UserEntity`, `SuiteEntity` та інші types. Models можна повторно використати через спільну library або підтримувати окремо в test project, якщо прямої залежності від application code немає. Backend flow часто проходить repository/DAO → entity → DTO → controller response. Розуміння цих перетворень допомагає локалізувати mismatch між database state й API JSON, але automation-код не повинен відтворювати всю production реалізацію.

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

Design Patterns для автоматизаторів · 1:46:30–1:50:36

Підсумок патернів і подальші теми

Підсумкова структура розділяє Page Object на сторінки й компоненти, підключає спільні компоненти композицією, передає робочі дані як State, створює їх через Factory Method і перевіряє готовність через Loadable Component. Fluent-виклики роблять сценарій коротшим, якщо не приховують переходи між контекстами, а helpers, decorators і utilities залишаються вузькими за відповідальністю. Автор анонсує окремий розбір Playwright-обгортки з Singleton, Observable і Command: один інстанс для тестів, очікування стану UI та об'єкти команд/conditions на зразок Selenide. Відео завершується нагадуванням структурувати тестовий проєкт поступово й подякою за збір коштів для військових.

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

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

Мінімальний набір повторюваних патернів

Автор підсумовує практичний набір: Page Object, Adapter/Delegate, Chain of Responsibility, Decorator, Facade, Value Object, Factory Method, Strategy, State, Controller і DTO. Це не каталог заради каталогу, а повторювані seams для UI, API, data generation і assertions. XUnit patterns також дають назви для assertion methods, assertion messages і test-data factories. Їх потрібно вводити після появи дублювання або нечіткого contract, а не будувати всі наперед.

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