Відеобібліотека
Пошук у нотатках курсу Design Patterns для автоматизаторів з переходом на потрібну секунду.
Один business scenario може мати різні UI-кроки на mobile/desktop Web або iOS/Android: відрізняються header, navigation, scrolling, calendar і time picker. Тест при цьому має залишатися спільним за наміром, а platform-specific дії — вибиратися окремо. Strategy пропонується як спосіб сховати ці відмінності за одним interface. Водночас для першого невеликого набору тестів звичайний `if` або `switch` може бути достатнім KISS-рішенням.
У прикладі пошук системного setting потребує scroll на iOS і іншої взаємодії на Android. `SettingsScreen` вибирає `IosSettings` або `AndroidSettings` за driver/platform і делегує однаковий публічний метод потрібній реалізації. Коли різниться багато screens і їх послідовність, кількість strategies швидко зростає. Для двох повністю native codebases автор інколи віддає перевагу окремим Swift/Kotlin test projects з однаковими test cases: вони ближчі до application code і їх легше запускати розробникам.
Playwright підтримує CSS, XPath, text і role-based locators. `getByRole` спирається на ARIA/accessibility semantics та accessible name, що особливо корисно для frameworks, які рендерять custom elements або `div` замість native controls. Role locator надійний лише тоді, коли frontend справді підтримує коректну accessibility structure. Якщо labels/roles генеруються випадково або команда їх не контролює, краще домовитися про стабільні attributes, ніж механічно слідувати документації.
Автор підсумовує практичний набір: 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, а не будувати всі наперед.