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

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

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

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

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

Custom waits, soft assertions і remote browsers

Native Playwright assertions є dynamic waits і покривають більшість visible/hidden/text conditions. Якщо потрібні custom polling або AssertJ soft assertions, їх можна викликати всередині власної condition через Awaitility-подібний wait, але це окреме розширення, а не default шлях. У headless CI Playwright працює без спеціальних змін, окрім встановлення browser binaries; BrowserStack і Sauce Labs також мають власні integration instructions. Перший запуск довший через download Chromium, WebKit і Firefox artifacts.

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

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

Response Decorator і custom assertions

Response wrapper/decorator може централізовано перевіряти status code, витягувати body та формувати зрозуміле failure message. Коли однакові checks дублюються між controllers, вони переносяться у resource-specific assertion class, наприклад assertions для suite response. Generated API clients часто кидають exceptions на `4xx/5xx`, через що negative tests змушені розбирати exception body і status. Окрема assertion layer може бути простішою. AssertJ-style generated assertions і обов'язкові пояснення `because` покращують grouping однакових failures у report.

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

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

Assertions і незручність сирого fluent API

Playwright Java розділяє locator actions і assertions: для перевірки потрібно окремо передавати locator в assertion API. Після action не завжди можна продовжити читабельний chain на тому самому object, тому Page Object наповнюється повторними locator calls. Автор прагне до Selenide-подібного стилю: знайти element, викликати `shouldBe`/`shouldHave`, виконати `click`, `setValue` або `press`, читаючи chain зліва направо. Замість великого framework потрібен вузький wrapper над уже наявними Playwright capabilities.

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

Design Patterns для автоматизаторів · 2:01–9:21

Прямий Selenide-сценарій і перевірка результату дій

Перший тест відкриває головну сторінку, шукає товар, переходить на сторінку товару, звіряє назву, додає товар до кошика й перевіряє його вміст. Під час ручного проходження сценарію автор перевіряє кількість збігів селектора та враховує можливу одночасну desktop/mobile-розмітку. Другий сценарій додає товар прямо зі сторінки результатів пошуку. Демонстрація показує, що слабка перевірка тексту може дати хибнопозитивний результат; після переходу на exact text тест очікувано падає. Тестові дані варто винести в одну змінну, щоб назва товару не розходилася між кроками.

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

Design Patterns для автоматизаторів · 47:00–52:38

Trace Viewer замість відео

Playwright trace зберігає actions, before/after snapshots, console, network requests, request/response bodies і metadata. Це дозволяє відкрити локальний Trace Viewer та побачити, що відбулося перед failure, без повторного запуску. Trace artifact може бути десятки megabytes, але часто дає більше діагностичної інформації за video. На CI варто зберігати trace для кожного test або при failure й публікувати його як downloadable artifact чи у власному hosted viewer. **Актуальність станом на 2026-08-08.** Низькорівневий `BrowserContext.tracing()` у Playwright Java записує browser operations і network activity, але не test assertions. Це обмеження треба врахувати, якщо wrapper обіцяє повний assertion-aware trace ([Playwright Java documentation](https://playwright.dev/java/docs/api/class-tracing)).

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

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

API versioning і OpenAPI models

`v1`, `v2` і наступні versions дозволяють підтримувати mobile clients та third-party integrations, які залежать від старого response shape. Tests для обох контрактів краще розділити явно, а не наповнювати один controller умовами. OpenAPI/Swagger schema може згенерувати request/response models і clients для Java, C#, Python або TypeScript. Це економить ручне створення DTO, але generated code потрібно перевірити: його default exception handling не завжди зручний для negative API assertions.

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

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. Патерни проєктування або чому огірок нікому не тре. →
Запитати в чаті про «assertions» →