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

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

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

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

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

Factory Method та централізовані набори даних

Створення великої тестової сутності переноситься у фабричний метод на кшталт отримання цільового товару. Це ховає довгу ініціалізацію, дає тесту коротке ім'я даних і дозволяє зібрати підготовлені продукти в окремому test-data класі, коли їх стає більше. Як альтернативу показано `enum`, де іменоване значення на кшталт `SIGMA_BOX` містить потрібні поля або готовий DTO. Тест тоді використовує стабільне доменне ім'я без додаткової локальної змінної. Автор радить не фіксувати структуру папок завчасно: спершу дані можуть жити поруч із тестом, а окремий пакет з'являється після появи реальної кількості сутностей.

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

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

TypeScript API-приклад і role-specific UI

У TypeScript-прикладі factory method створює registration DTO з random data, Controller приймає DTO, Axios config зберігає базові settings, а response decorator порівнює фактичний JSON з типізованою model. Якщо поле відсутнє, custom error підказує class і type, які потрібно оновити. Для продукту з різними clients, roles і permissions UI-перевірки краще групувати невеликими components або role-specific classes. Менші класи полегшують code review і зменшують merge conflicts, але надмірне дроблення так само небажане; shared page behavior залишається спільним.

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