Патерн Screenplay: сучасний підхід до автоматизації тестування

У цій статті ми розглянемо патерн Screenplay — інноваційний підхід, який змінює фокус із технічних деталей на поведінку користувачів та їхні цілі. Завдяки цьому патерну автоматизовані тести стають більш зрозумілими, модульними та легкими в підтримці, що особливо важливо для великих команд і складних систем.

Якщо ви вже маєте певний досвід у сфері автоматизації тестування, то, найімовірніше, чули про Page Object Model (POM) — патерн, що організовує автоматизацію інтерфейсу користувача навколо сторінок та їхніх елементів. І він насправді чудово працює... доки ваш проєкт не починає зростати. Тоді раптово класи сторінок стають громіздкими, логіка дублюється між тестами, а підтримка перетворюється на справжнє випробування.

Тож патерн Screenplay пропонує свіжий погляд на розв’язання цієї проблеми. Замість того щоб зосереджуватися на сторінках, він фокусується на людях — користувачах (або системах), які взаємодіють із вашим застосунком, та цілях, яких вони прагнуть досягти.

Він дає змогу моделювати автоматизацію як історії поведінки користувачів, а не як набір технічних дій та кліків.

Що таке патерн Screenplay?

Патерн Screenplay — це орієнтований на користувача підхід до створення автоматизованих тестів.

В його основі лежить театральна метафора — уявімо ваші тести як театральну виставу:

• сцена — це продукт, який ви тестуєте;
• актори — користувачі або сервіси, що взаємодіють із ним;
• сценарій, що складається із завдань та цілей, які виконують актори.

Така ментальна модель допомагає тестувальникам описувати, що саме відбувається в тесті, а не лише як це відбувається технічно.

На відміну від традиційних підходів, де логіка тестів безпосередньо прив'язана до сторінок інтерфейсу, патерн Screenplay сприяє незалежності, модульності та чіткості намірів. Його можна застосовувати не лише для тестування вебінтерфейсів, але й для API, мобільних застосунків та інтеграційного тестування.

Основні складники:

Щоб краще зрозуміти Screenplay, корисно уявити його як ієрархію ролей та поведінок:

Актори — хто виконує тест?

Актори уособлюють сутності, що взаємодіють із вашою системою — зазвичай це користувач, але також може бути інший сервіс, фонове завдання чи зовнішній API. Кожен актор має певну мету та набір здібностей, які визначають його можливості.

Здібності — набір інструментів актора?

Здібності відповідають на питання «як актор це робить?». Якщо актор має взаємодіяти з вебсайтом, йому потрібна здібність «переглядати вебсторінки». Якщо з API — здібність «робити API-запити».

Без потрібних здібностей актор не може виконати жодного завдання. Це його технічне оснащення.

Завдання — чого прагне досягти актор?

Завдання — це високорівневі, бізнес-орієнтовані дії. Замість опису на кшталт «натиснути тут» чи «ввести туди», ви описуєте змістовні кроки, наприклад:

• «увійти в систему»;
• «оформити замовлення»;
• «додати пункт до списку завдань».

Кожне завдання складається з дрібніших, більш технічних взаємодій, але приховує ці деталі — це допомагає тестам залишатися зрозумілими та зосередженими на меті, а не на технічній реалізації.

Запитання — що актор має перевірити?

Актори не лише виконують дії — вони також ставлять запитання, щоб переконатися, що система відреагувала належним чином.

Наприклад:

• «яке повідомлення відображається на головній сторінці?»;
• «який текст містить останній елемент у списку?»;
• «чи активна кнопка 'Відправити'?»

Запитання відокремлюють логіку перевірки від логіки взаємодії, що підвищує чіткість тестів та можливість їх повторного використання.

Теорія звісно важлива, але саме код дає нам повне розуміння концепції. Тож розглянемо моделювання простого сценарію «списку справ» за допомогою C#, NUnit та фреймворку Boa Constrictor.

Наша мета: актор має додати новий пункт до свого списку справ і пересвідчитися, що він з'явився.

1. Актор та його здібності

Насамперед визначимо нашого Актора, «Венді», та надамо їй здібність працювати з вебсторінками за допомогою Selenium IWebDriver. Зазвичай це реалізується в методі [SetUp] тестового класу.

2. Завдання та його взаємодії

Далі, створюємо високорівневий ITask для додавання елемента. Клас завдання інкапсулює необхідну послідовність дій. UI-локатори при цьому виносимо в окремий статичний клас.

3. Запитання

Тепер нам потрібне IQuestion для отримання тексту останнього доданого пункту в списку. Boa Constrictor надає вбудоване запитання Text, яке ми можемо використати з нашим локатором.

Це Питання не є самою перевіркою. Його завдання — лише «запитати» систему про її стан і принести відповідь. А вже цю відповідь ми перевірятимемо окремо.

4. Об'єднуємо все в тесті

Нарешті, поєднуємо Актора, Завдання та Запитання в зрозумілий тест NUnit. Для виконання перевірки використовуємо клас Assert із NUnit.

Цей тест розповідає чітку історію: Венді переходить на сторінку, додає пункт до списку справ, робить запит тексту і перевіряє, що він правильний.

Чому це важливо: ключові переваги

Патерн Screenplay забезпечує структуру, масштабованість і комунікаційні переваги, що виходять за межі стилю коду.

1. Зрозумілі та бізнес-орієнтовані тести

Тести перетворюються на виразні розповіді про поведінку. Така ясність легко долає розрив між технічними та нетехнічними зацікавленими сторонами.

Погляньте лише на тестовий скрипт з нашого прикладу:

2. Повторне використання та модульність

Оскільки Завдання та Запитання є самодостатніми, їх можна повторно використовувати в різних сценаріях. Замість дублювання кроків «входу в систему», ви повторно використовуєте завдання LogIn — одного разу визначене, воно може застосовуватися багаторазово. Це суттєво зменшує дублювання коду.

3. Розділення відповідальності

Патерн Screenplay чітко розділяє:

• що користувач хоче зробити (ITask: AddATodoItem);
• як це робиться (взаємодія: SendKeys);
• як це перевіряється (IQuestion та Assert: Text.Of та Assert.That).

Таке розділення полегшує підтримку та розвиток вашого тестового фреймворку.

4. Масштабованість для великих команд

Коли кілька команд працюють над одним проєктом автоматизації, Screenplay забезпечує чіткий словник та структуру. Різні інженери можуть відповідати за різні здібності чи завдання, тоді як самі тести залишаються послідовними та легкими для розуміння.

Патерн Screenplay проти Page Object Model

Page Object Model (POM) організовує автоматизацію навколо сторінок інтерфейсу.

Це працює добре на початку, але швидко може призвести до:

• величезних, некерованих класів для складних сторінок;
• тісного зв'язку між логікою тестів та деталями інтерфейсу;
• дубльованої логіки для користувацьких сценаріїв, що охоплюють кілька сторінок.

Натомість патерн Screenplay:

• зосереджується на цілях користувача, а не на сторінках;
• заохочує створення малих, компонованих складників (Завдання, Запитання);
• не обмежується тестуванням інтерфейсу; той самий Актор може отримати Здібність CallAnApi.

Підсумуємо:

1. POM відповідає на питання «Де щось відбувається?».
2. Screenplay відповідає на питання «Хто це робить і чому?».

Як почати використовувати патерн Screenplay

Хороша новина у тому, що вам не потрібно перебудовувати весь фреймворк з нуля.

Ось ваш практичний шлях:

1. Почніть з малого: оберіть просту, стабільну функцію — наприклад, вхід користувача в систему — і змоделюйте її за допомогою підходу Screenplay. Коли відчуєте себе впевненіше, починайте поступово рефакторити й інші тести.
2. Використовуйте наявні бібліотеки: кілька фреймворків з відкритим кодом реалізують патерн Screenplay, надаючи готові до використання абстракції, щоб ви могли зосередитися на поведінці, а не на шаблонному коді.
3. Розвивайтеся поступово: впроваджуйте Screenplay поряд із наявними Page Objects. З часом Завдання та Взаємодії можуть замінити строгу ієрархію сторінок, що призведе до чистішої архітектури.

Патерн Screenplay — це не просто ще один фреймворк автоматизації, а зміна мислення.

Він спонукає нас думати з погляду цілей користувача, а не технічних кроків, роблячи наші тести:

• більш виразними та легшими в підтримці;
• простішими для масштабування між командами та рівнями;
• застосовними для UI, API та інших сфер.

Зрештою, йдеться про створення кращих сценаріїв тестування. Ваші тестові скрипти стають розповідями, де актори переслідують цілі, використовують свої здібності та перевіряють результати — так само як це робив би реальний користувач.

Тож наступного разу, коли ви почнете проєктувати новий тест, запитайте себе: хто мій актор, чого він намагається досягти, і яку історію розповідає мій тест?

Першоджерело