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

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

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

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

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

DTO і Builder для комплексних тестових даних

Одного рядка з назвою товару недостатньо, коли пошук і перевірки використовують також `id`, ціну, рейтинг, доступність чи інші поля. `ProductInfoDto` групує ці значення в одну сутність, щоб не розширювати кожен метод двома, трьома або більшою кількістю аргументів. Builder робить ініціалізацію Java-об'єкта читабельною: значення прив'язуються до названих полів, а не передаються довгим позиційним конструктором. У прикладі boilerplate генерує Lombok. Автор також згадує Java records як коротший immutable-варіант, але залишає DTO змінюваним для сценаріїв, де тестові дані потрібно оновлювати.

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 для автоматизаторів · 6:00–13:00

Порівняння runtime Selenium і Playwright

Один login/business flow запускається спочатку через Selenium, а потім через Playwright. У демонстрації Selenium-виконання займає близько хвилини, тоді як Playwright проходить той самий flow приблизно за десять секунд. Playwright Java описується як client для взаємодії з browser через DevTools protocol. Швидкість не скасовує testability проблем, але зменшує protocol overhead і дає швидший feedback.

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

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 для автоматизаторів · 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:49:21–1:52:04

Мова, масштаб UI-suite і підсумок wrapper

Приклад лишається на Java, але той самий маленький wrapper можна реалізувати на Python, C# або TypeScript. Для JavaScript/TypeScript автор радить TypeScript через типізацію. На проєктах, де architecture дозволяє тестувати основну логіку на API-рівні, UI-suite може складатися приблизно з десяти ключових flows. Тоді мінімальна обгортка, Page Objects і Trace Viewer дають достатню підтримуваність без створення ще одного великого framework.

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

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

Чому raw Selenium погано масштабується

Raw Selenium створює повтори `findElement`, waits і JavaScript executor workarounds, тому починати радять хоча б з існуючого wrapper на кшталт Selenide. Змішування implicit та explicit waits додатково робить runtime і причину затримки непередбачуваними. На CI test code, Selenium Server і browser можуть працювати на різних machines. Кожна remote команда додає network latency та навантаження Grid/Selenoid, тому велика кількість дрібних звернень до browser різко збільшує загальний час.

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

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

Селектори, KISS і Proof of Concept

Для селекторів потрібна або впевнена навігація DOM-деревом, або командна домовленість про стабільні `data-*` атрибути; за потреби тестувальник може сам додати їх у frontend і перевірити зміни локально. Автоматизацію радять починати з найпростішого Proof of Concept, щоб рано виявити bot protection, проблемні локатори та інші обмеження системи. Сценарій має підтверджувати бізнес-ціль, а не просто взаємодію з UI. Для e-commerce початковою перевіркою обрано додавання товару до кошика з подальшим підтвердженням результату.

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

Design Patterns для автоматизаторів · 0:00–6:36

Одна поведінка для різних платформ

Один business scenario може мати різні UI-кроки на mobile/desktop Web або iOS/Android: відрізняються header, navigation, scrolling, calendar і time picker. Тест при цьому має залишатися спільним за наміром, а platform-specific дії — вибиратися окремо. Strategy пропонується як спосіб сховати ці відмінності за одним interface. Водночас для першого невеликого набору тестів звичайний `if` або `switch` може бути достатнім KISS-рішенням.

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

Design Patterns для автоматизаторів · 0:00–9:14

Native і cross-platform технології

Flutter і React Native дозволяють розвивати iOS та Android з однієї основної codebase, а native-модулі підключати для Bluetooth, geolocation, notifications чи інших можливостей системи. Це прискорює MVP, але native-застосунки на Swift і Kotlin зазвичай мають менше проміжних шарів і працюють швидше. Навіть у cross-platform продукті команди часто розділяються за iOS/Android або за product streams. Тестувальнику потрібно розуміти специфіку кожної платформи, а не вважати однакову codebase гарантією однакової поведінки.

Мобільне тестування та автоматизація →
Запитати в чаті про «java» →