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

1

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

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

2

О себе

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

Automation Tech/Team LeadISsoft / Coherent Solutions

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

http://www.coherentsolutions.com/

http://www.comaqa.by/

http://www.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”


24

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


25

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


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

26

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


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


36


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): “Каждый фрагмент знаний должен иметь единственное, однозначное, надежное представление в сисиеме” - Эндрю Хант и Дэйв Томас в книге «Программист-прагматик»


=

45

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

http://www.coherentsolutions.com/

http://www.comaqa.by/

http://www.dpi.solutions/

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

Education