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

Design Patterns для автоматизаторів · 9:21–16:31

DRY, DAMP, KISS і YAGNI у тестах

Спільне відкриття сторінки переноситься в `beforeEach`, а повторювані кроки пошуку та перевірки — у методи з явними назвами. Метод має описувати дію в контексті поточної сторінки або компонента; якщо контекст відрізняється, поведінку краще рознести. DRY не означає механічно виносити кожен повтор. Спочатку корисно написати прямий читабельний сценарій, переконатися, що він перевіряє наслідок кожної дії, і лише тоді прибирати дублювання. DAMP, KISS і YAGNI стримують передчасну архітектуру та допомагають зберегти тест зрозумілим.

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

Design Patterns для автоматизаторів · 0:00–2:01

Селектори, KISS і Proof of Concept

Для селекторів потрібна або впевнена навігація DOM-деревом, або командна домовленість про стабільні `data-*` атрибути; за потреби тестувальник може сам додати їх у frontend і перевірити зміни локально. Автоматизацію радять починати з найпростішого Proof of Concept, щоб рано виявити bot protection, проблемні локатори та інші обмеження системи. Сценарій має підтверджувати бізнес-ціль, а не просто взаємодію з UI. Для e-commerce початковою перевіркою обрано додавання товару до кошика з подальшим підтвердженням результату.

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

Design Patterns для автоматизаторів · 0:00–6:36

Одна поведінка для різних платформ

Один business scenario може мати різні UI-кроки на mobile/desktop Web або iOS/Android: відрізняються header, navigation, scrolling, calendar і time picker. Тест при цьому має залишатися спільним за наміром, а platform-specific дії — вибиратися окремо. Strategy пропонується як спосіб сховати ці відмінності за одним interface. Водночас для першого невеликого набору тестів звичайний `if` або `switch` може бути достатнім KISS-рішенням.

2. API. Патерни проєктування або чому огірок нікому не тре. →

Design Patterns для автоматизаторів · 6:36–15:18

Реалізація Strategy і межа її складності

У прикладі пошук системного setting потребує scroll на iOS і іншої взаємодії на Android. `SettingsScreen` вибирає `IosSettings` або `AndroidSettings` за driver/platform і делегує однаковий публічний метод потрібній реалізації. Коли різниться багато screens і їх послідовність, кількість strategies швидко зростає. Для двох повністю native codebases автор інколи віддає перевагу окремим Swift/Kotlin test projects з однаковими test cases: вони ближчі до application code і їх легше запускати розробникам.

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