Відеобібліотека
Пошук у нотатках курсу Design Patterns для автоматизаторів з переходом на потрібну секунду.
Request і response радять представляти типізованими objects, а не збирати JSON-рядки вручну. DTO групує поля suite, user чи report і дозволяє controller приймати один аргумент замість довгої сигнатури. На ранньому етапі можна тимчасово витягнути одне поле через JSONPath, якщо повна model ще не потрібна. Коли перевірки розширюються до всього response, цей seam замінюється DTO без зміни business flow тесту.
Одного рядка з назвою товару недостатньо, коли пошук і перевірки використовують також `id`, ціну, рейтинг, доступність чи інші поля. `ProductInfoDto` групує ці значення в одну сутність, щоб не розширювати кожен метод двома, трьома або більшою кількістю аргументів. Builder робить ініціалізацію Java-об'єкта читабельною: значення прив'язуються до названих полів, а не передаються довгим позиційним конструктором. У прикладі boilerplate генерує Lombok. Автор також згадує Java records як коротший immutable-варіант, але залишає DTO змінюваним для сценаріїв, де тестові дані потрібно оновлювати.
У 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 залишається спільним.
Створення великої тестової сутності переноситься у фабричний метод на кшталт отримання цільового товару. Це ховає довгу ініціалізацію, дає тесту коротке ім'я даних і дозволяє зібрати підготовлені продукти в окремому test-data класі, коли їх стає більше. Як альтернативу показано `enum`, де іменоване значення на кшталт `SIGMA_BOX` містить потрібні поля або готовий DTO. Тест тоді використовує стабільне доменне ім'я без додаткової локальної змінної. Автор радить не фіксувати структуру папок завчасно: спершу дані можуть жити поруч із тестом, а окремий пакет з'являється після появи реальної кількості сутностей.
`ProductInfoDto` передається в конструктор `ProductItem` один раз і стає станом компонента. Методи `hasTitle`, `addToCart` та `openProductPage` використовують той самий товар без повторення аргумента в кожному виклику. Це корисно, коли багато методів одного класу працюють з одними й тими самими даними. `ProductList` надає фабричний метод, який створює `ProductItem` для потрібного товару. Всередині компонента спільний батьківський selector картки формується один раз з `id`, а конкретні методи звужують пошук до title чи кнопки. Так selector scope і стан залишаються локальними для картки, а тест не знає її DOM-структури.
`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.
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 реалізацію.
Автор підсумовує практичний набір: 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, а не будувати всі наперед.
Для environment і platform радять використовувати typed enums замість порівняння випадкових strings: `dev`, `stage`, `prod`, `iOS`, `Android`, `Web`. Це дає autocomplete і чітко обмежує допустимі значення. Завершальна думка: Controller, DTO та інші патерни мають залишатися гнучкими й простими. Структура тестів починається з фактичної architecture та поточного contract, а ускладнюється лише коли з'являється відповідна проблема.