Как не изобретать велосипед, или паттерны...

1

Как не изобретать велосипед, или паттерны проектирования

для автотестовВадим Зубович

2

О себе

Вадим Зубович

Automation Tech/Team LeadISsoft / Coherent Solutions

www.coherentsolutions.comwww.comaqa.bywww.dpi.solutions

3

Создать чистую

архитектуру

Главные трудности при написании автотестов

Избежать перегруженн

ой архитектуры

4

Инкапсуляция – важнейший принцип ООП

Казалось бы, при чем здесь инкапсуляция?

5

Инкапсуляция – важнейший принцип ООП

Она лежит в основе всех рассматриваемых паттернов, а стало быть понимание и применение ее является ключевым для правильного понимания паттернов

6

Что такое инкапсуляция?

Инкапсуляция это ограничение доступа к внутренним данным одного компонента программы для других компонентов, с предоставлением готового интерфейса для доступа к этим данным.

Иными словами:

Мы скрываем логику и детали реализации алгоритма, создаем механизмы и правила изменения внутренних данных и предоставляем возможность изменять эти данные в соответствии с созданными правилами.

Инкапсуляция – важнейший принцип ООП

7

Пример на пальцах

Инкапсуляция – важнейший принцип ООП

8

Элементы (блоки) готового к повторному использованию кода;

Паттерны проектирования – простейшее определение

Готовая к повторному использованию форма решения архитектурной задачи;

9

Паттерны проектирования, которые относятся к определенной области (например автоматизация тестирования) называется языком паттернов (pattern language)

Паттерны проектирования как язык

Язык паттернов проектирования обеспечивает общую терминологию для обсуждения и решения проблем, с которыми сталкиваются специалисты

10

Паттерны, относящиеся к области автоматизации тестирования:

Паттерны проектирования для автоматизации тестирования

• Page Element• Page Object• Action• Flow• DSL• Navigator (for Web)

11

Page Element – инкапсулирует «сложность» отдельного UI-элемента. Каноничный пример – таблица как часть пользовательского интерфейса.

Page Element

12

Page Element

13

Page Element

14

Page Element

15

Page Element

16

Page Object – инкапсулирует способ идентификации и логическое группирование элементов.

Page Object

17

Page Object по Мартину Фаулеру, правило логической страницы

Page Object == Logical PagePage Object != Physical Page

Header

Menu

Footer

Conten

t

18

Где должны находиться проверки (asserts)?

Page Object по Мартину Фаулеру, правило проверок

19

Статический класс

Объект или статический класс?

20

Объект

Объект или статический класс?

21

Вывод

Объект или статический класс?

– В подавляющем большинстве случаев предпочтительнее использовать решения на базе статических классов (stateless);

– Прежде чем использовать решение с использованием объектов, сделайте перерыв, подумайте снова, возможно вы найдете подходящее решение на базе статических классов.

22

UI работает в режиме “Wizard”

Page Object на базе объектов, особые случаи

23

Веб UI вместе с мобильным “native view”

Page Object на базе объектов, особые случаи

24

Интернет вещей (в большинстве случаев)

Page Object на базе объектов, особые случаи

25

Сложные сценарии, подразумевающие переходы более чем на 1 страницу в рамках одного теста (например несколько порталов или разных страниц одного приложения передают друг другу данные в рамках одного “business use case”):

Page Object на базе объектов, особые случаи

– Такое встречается редко;– Больше похоже на интеграционные тесты.

26

Добавьте ваши примеры

Page Object на базе объектов, особые случаи

27

Page Object – Архитектура проекта

28

Action – набор вызовов низкоуровневых функций (в нашем случае Selenium или оберток над ним), объединенных одним пользовательским действием.

Action

29

Action как правило используется совместно с паттернами Page Element и Page Object.

Action

30

Слой Action может быть представлен отдельно от слоя Page Object.

Action

31

2 «типа» Actions:

Action

Ориентированные на автоматизаторов

Ориентированные на «бизнес» (~Product Owner)

может содержать буквально несколько строк кода для облегчения работы с элементами

может включать в себя целый тест

32

В подавляющем большинстве случаев не стоит хранить проверки в Action:

Action - рекомендация

– Нет смысла проверять одну и ту же часть функционала при каждом вызове;– Такой подход может продлить время прогона тестов;

33

Flow – Fluent interface это реализация объектно-ориентированного API, целью которой является повышение читаемости кода.

Flow по определению wiki

Fluent interface обычно реализуется с использованием «каскадирования» методов (конкретнее - построения цепочки методов) чтобы предоставить дополнительный контекст в виде последующих вызовов (однако fluent interface характеризуется не только построением цепочек).

Как правило контекст определяется через возвращаемое методом значение, и прекращается возвращением пустого значения (тип void).

34

Flow – пример

35

Flow – пример

36

Flow – пример

37

Основная идея DSL заключается в создании компьютерного языка, ориентированного на решение конкретной задачи (Автоматизация тестирования или даже автоматизация в конкретном домене), а не языка общего назначения, который ориентирован на решение любой задачи. Доменно-специфичные языки существуют и используются с самых первых дней вычислительной техники.

DSL по Мартину Фаулеру

38

DSL = Язык, специфичный для доменаБизнес домена

Технического домена

DSL – Domain Specific Language

39

Писать тесты на какой-либо форме доменно-специфичного языка является распространенным явлением, например Cucumber. Если прибегать к этому подходу, то лучше всего создавать этот слой поверх page object, чтобы в итоге получился парсер, который будет преобразовывать выражения на DSL в вызовы методов на page object.

DSL по Мартину Фаулеру

40

Внутренние DSL - использование языка общего назначения таким образом, что ему придаются свойства определенного узконаправленного языка. Такой подход получил огромную популярность в Ruby-сообществе, хотя у него была богатая история в других языках, например в Lisp. Хотя обычно проще это делать в низкоуровневых языках, можно успешно реализовывать внутренние DSL в более распространенных языках, как Java и C#. Внутренние DSL также называют вложенными DSL

Типы DSL по Мартину Фаулеру

Внешние DSL характеризуются своим собственным синтаксисом и для них пишутся полноценные парсеры. В Unix community давно существует традиция создания подобных языков. Многие конфигурации XML стали в итоге внешними DSL.

41

Navigator – следует принципам “DRY” и “Single source of truth”, инкапсулирует «сложность» ссылок/переходов по веб-страницам, таким образом бизнес-логика не смешивается с перемещением по приложению.

Navigator (for Web)

42

Navigator (for Web)

43

1. “Если в ваших тестовых методах есть обращения к WebDriver API, вы делаете это неправильно.” – Саймон Стюарт

3 главных принципа / правила

=

44

2. Не повторяйся (DRY): “Каждый фрагмент знаний должен иметь единственное, однозначное, надежное представление в сисиеме” -  Эндрю Хант и Дэйв Томас в книге «Программист-прагматик»

3 главных принципа / правила

=

45

3. “Теория разбитых окон” -  Эндрю Хант и Дэйв Томас в книге «Программист-прагматик»

3 главных принципа / правила

=

46

Page Object – универсальный паттерн, подходящий для любого проекта

Выводы

Page Element годится для случаев, когда на проекте есть повторяющиеся в неизменном, либо изменяемом виде сложные элементы, состоящие из набора простых элементов (таблица, строка поиска, форма)

Action – упрощение работы с Page Object, следовательно имеет смысл на большинстве проектов

Fluent interface – хорош, если есть потребность в приближении кода тестов к бизнес-домену, кроме того исключает возможность нарушить бизнес-логику

DSL – разработка своего DSL хороша лишь в том случае, если стандартные инструменты не позволяют провести тестирование (например тестирование через API приложения)

Navigator – подходит для проектов со сложной структурой приложения

47

Спасибо за внимание

Вадим ЗубовичISSoft Solutions

www.coherentsolutions.comwww.comaqa.by

www.dpi.solutions