Test Automation Design Patterns

Привіт, мене звати Артем Овчаренко. Я лід тест автоматизатор на JS і це 1-ша стаття з серії статей про паттерни проектування для автоматизації саме на JS або Software Design Patterns for JS Automation.

Перше з чого ми почнемо – визначення. 

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

Якщо пояснювати просто – у вас є програма і в ній виникнула проблема, ви вирішили цю проблему придумавши рішення, назвемо його Рішення1. В той самий час в мене виникла така сама проблема, але в іншій програмі, і я придумав Рішення2. Рішення1 і Рішення2 схожі, проте мають відмінності. Ми зустрілись, обговорили ці два рішення і виявили схожі частини коду. Задокументували ці частини, зробили універсальними, та дали назву. Все – паттерн готовий.

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

Аналогія до алгоритму - це рецепт приготування страви. І рецепт і алгоритм мають чіткі кроки для досягнення мети. На противагу їм, паттерн більше схожий на схему: ви бачите, який буде результат і його особливості, але конкретний порядок виконання залишається на ваш розсуд.

Чому важливо знати паттерни?

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

Є й інші причина розібратись з паттернами. По-перше, це спільна термінологія, яку можна використовувати для більш ефективного спілкування. Можна сказати: "Та просто використовуйте Page Object", і кожен автоматизатор зрозуміє ідею. Немає потреби пояснювати, що таке пейдж обжект, якщо всі знають патерн і його назву.

З чого складається паттерн? 

Більшість паттернів описуються дуже формально, щоб люди могли відтворити їх в різних контекстах. Тому кожен паттерн має містити наступну інформацію:

-      Мета – або чому він був винайдений, яку проблемі він вирішує

-      Структура класів – зображує всі складові частини та взаємозв'язки між ними.

-      Приклади – ну куди ж без них.

Розділяють 3 группи паттернів, спираючись на їхню мету:

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

-      Structural або Структурні патерни пояснюють, як збирати об'єкти та класи в більші комплексні структури, залишаючи ці структури гнучкими та ефективними у використанні. 

-      Behavioral або Поведінкові патерни забезпечують ефективну комунікацію та розподіл обов'язків між об'єктами.

Які ж патерни використовуються в автоматизації?

Почну з тих, які точно потрібно знати автоматизатору (з моєї точки зору). Прошу в коментарі – якщо маєте іншу думку.

Creational:

-      Singleton – допомагає контролювати, що існує лише один екземпляр класу

-      Factory – створює різні обʼєкти, в залежності від певної умови

-      Builder – дозволяє будувати обʼєкти певного типу наповнюючи їх обраною інформацією

Structural:

-      POM (page object model) – найбільш необхідний паттерн для WEB автоматизації. Структурує код, що описує сторінки та дозволяє уникати дублікатів коду

-      Composite – використовують для випадків коли є деревоподібні структури типу: випадаючий список з випадаючим списком в середині.

-      Facade – ховає складну логіку та дає доступ простого API

-      Decorator – додає нові властивості чи логіку існуючому обʼєкту, функції, класу

Behavioral:

-      Strategy – виконує певний код в залежності від умови (чимось схожий на Factory тільки не створює обʼєкти)

Які ще існують патерни? 

Creational:

      Prototype

Structural:

      Adapter      Proxy      Bridge      Flyweight      Proxy

Behavioral:

      Chain of Responsibility      Command      Iterator      Mediator

      Memento      Observer      State      Template Method      Visitor

Більше детально про Design Pattern (окрім POM) можна почитати на Refactoring.guru.

А поки давайте розглянемо наступні терміни:

TDD, BDD, BDT, DDT, TDT

Час від часу можна зустріти думку, що це теж шаблони проектування. Проте спираючись на ISTQB:

-      TDD – test-driven development – техніка розробки програмного забезпечення, при якій тест кейси спочатку розробляються, потім автоматизуються, а потім програмне забезпечення розробляється поетапно для проходження цих тестових кейсів.

-      BDD – behavior-driven development – підхід (думаю тут вони теж хотіли написати техніка розробки програмного забезпечення) до розробки, при якому команда спрямована на надання очікуваної поведінки компонента або системи для замовника, що становить основу для тестування.

-      BDT – behavior-driven testing – ISTQB про це нічого не знає проте, інтернети кажуть - це метод тестування, в якому сценарії тестування базуються на поведінці користувача. Часто плутують з BDD, BDT ґрунтується на структурі given-when-then та сприяє кращій співпраці команди тестування з бізнесом та швидкому виходу на ринок (але це не точно 😅).

-      DDT / TDT – data-driven testing або table-driven testing або parameterized testing – ISTQB знову про це не в курсі – методологія тестування програмного забезпечення, яка використовує таблицю безпосередніх тестові данних та відповідні їм перевіряємі очікувані результати.

п.с. наступна стаття буде по Page Object-у. Stay tuned.