Доклад Вадима Зубовича на конференции SQA Days-20. 24-26 ноября 2016. Минск www.sqadays.com

1. 1
Как не изобретать велосипед,
или паттерны проектирования
для автотестов
Вадим Зубович

2. 2
О себе
Вадим Зубович
Automation Tech/Team Lead
ISsoft / Coherent Solutions
www.coherentsolutions.com
www.comaqa.by
www.dpi.solutions

3. 3
Создать чистую
архитектуру
Главные трудности при написании автотестов
Избежать
перегруженной
архитектуры

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

5. 5
Инкапсуляция – важнейший принцип ООП
Она лежит в основе всех рассматриваемых паттернов, а стало быть понимание и
применение ее является ключевым для правильного понимания паттернов

6. 6
Что такое инкапсуляция?
Инкапсуляция это ограничение доступа к внутренним данным одного компонента
программы для других компонентов, с предоставлением готового интерфейса для доступа
к этим данным.
Иными словами:
Мы скрываем логику и детали реализации алгоритма, создаем механизмы и правила
изменения внутренних данных и предоставляем возможность изменять эти данные в
соответствии с созданными правилами.
Инкапсуляция – важнейший принцип ООП

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

8. 8
Элементы (блоки) готового к повторному использованию кода;
Паттерны проектирования – простейшее определение
Готовая к повторному использованию форма решения архитектурной задачи;

9. 9
Паттерны проектирования, которые относятся к определенной области (например
автоматизация тестирования) называется языком паттернов (pattern language)
Паттерны проектирования как язык
Язык паттернов проектирования обеспечивает общую терминологию для обсуждения и
решения проблем, с которыми сталкиваются специалисты

10. 10
Паттерны, относящиеся к области автоматизации тестирования:
Паттерны проектирования для автоматизации
тестирования
• Page Element
• Page Object
• Action
• Flow
• DSL
• Navigator (for Web)

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

12. 12
Page Element

13. 13
Page Element

14. 14
Page Element

15. 15
Page Element

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

17. 17
Page Object по Мартину Фаулеру, правило логической
страницы
Page Object == Logical Page
Page Object != Physical Page
Header
Menu
Footer

18. 18
Где должны находиться проверки (asserts)?
Page Object по Мартину Фаулеру, правило проверок

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

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

21. 21
Вывод
Объект или статический класс?
– В подавляющем большинстве случаев предпочтительнее использовать решения на базе
статических классов (stateless);
– Прежде чем использовать решение с использованием объектов, сделайте перерыв,
подумайте снова, возможно вы найдете подходящее решение на базе статических классов.

22. 22
UI работает в режиме “Wizard”
Page Object на базе объектов, особые случаи

23. 23
Веб UI вместе с мобильным “native view”
Page Object на базе объектов, особые случаи

24. 24
Интернет вещей (в большинстве случаев)
Page Object на базе объектов, особые случаи

25. 25
Сложные сценарии, подразумевающие переходы более чем на 1 страницу в рамках одного
теста (например несколько порталов или разных страниц одного приложения передают
друг другу данные в рамках одного “business use case”):
Page Object на базе объектов, особые случаи
– Такое встречается редко;
– Больше похоже на интеграционные тесты.

26. 26
Добавьте ваши примеры
Page Object на базе объектов, особые случаи

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

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

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

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

31. 31
2 «типа» Actions:
Action
Ориентированные на автоматизаторов Ориентированные на «бизнес» (~Product Owner)
может содержать буквально несколько строк кода
для облегчения работы с элементами
может включать в себя целый тест

32. 32
В подавляющем большинстве случаев не стоит хранить проверки в Action:
Action - рекомендация
– Нет смысла проверять одну и ту же часть функционала при каждом вызове;
– Такой подход может продлить время прогона тестов;

33. 33
Flow – Fluent interface это реализация объектно-ориентированного API, целью которой
является повышение читаемости кода.
Flow по определению wiki
Fluent interface обычно реализуется с использованием «каскадирования» методов
(конкретнее - построения цепочки методов) чтобы предоставить дополнительный контекст
в виде последующих вызовов (однако fluent interface характеризуется не только
построением цепочек).
Как правило контекст определяется через возвращаемое методом значение, и
прекращается возвращением пустого значения (тип void).

34. 34
Flow – пример

35. 35
Flow – пример

36. 36
Flow – пример

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

38. 38
DSL = Язык, специфичный для домена
Бизнес домена
Технического домена
DSL – Domain Specific Language

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

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

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

42. 42
Navigator (for Web)

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

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

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

46. 46
Page Object – универсальный паттерн, подходящий для любого проекта
Выводы
Page Element годится для случаев, когда на проекте есть повторяющиеся в
неизменном, либо изменяемом виде сложные элементы, состоящие из набора простых
элементов (таблица, строка поиска, форма)
Action – упрощение работы с Page Object, следовательно имеет смысл на большинстве
проектов
Fluent interface – хорош, если есть потребность в приближении кода тестов к бизнес-
домену, кроме того исключает возможность нарушить бизнес-логику
DSL – разработка своего DSL хороша лишь в том случае, если стандартные
инструменты не позволяют провести тестирование (например тестирование через
API приложения)
Navigator – подходит для проектов со сложной структурой приложения

47. 47
Спасибо за внимание
Вадим Зубович
ISSoft Solutions
www.coherentsolutions.com
www.comaqa.by
www.dpi.solutions