Відеобібліотека
Пошук у нотатках курсу 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 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.
Для послідовних дій методи можуть повертати `this`, щоб після перевірки компонента викликати наступну дію через крапку. У відео це названо `chain of invocation` або `chain of responsibility`; Builder наведено як споріднений fluent-приклад. Ланцюжки потрібно форматувати за логічними частинами й переносити, коли рядок стає важко читати на code review. Автор переважно радить повертати той самий тип у межах сторінки чи компонента, а наступну сторінку створювати явно. Інакше, наприклад після `submit`, важко залишитися в контексті форми та перевірити validation errors; повернення іншого типу доречне лише за зрозумілою домовленістю команди.