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

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

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

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

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

Utility-класи, Decorator та extension-підходи

Великі `Utils` і base classes названо code smell: туди часто потрапляють непов'язані операції з файлами, датами, рядками й числами, частина яких не використовується. Мінімальне покращення — розділити helpers за типом або конкретною відповідальністю, наприклад date чи string operations. Для перетворення дати показано object-oriented альтернативу: Decorator отримує початкове значення як стан і надає пов'язані операції без глобального статичного контейнера. Для Kotlin, TypeScript і C# автор також згадує extension-підходи, що дозволяють викликати перетворення біля самого типу; вибір залежить від можливостей мови та кількості потрібних операцій.

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

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 для автоматизаторів · 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. Патерни проєктування або чому огірок нікому не тре. →

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