Паттерны тестирования. Велосипед первый: GUI-Domain-Test-Report

Паттерны тестирования.
Велосипед первый: GUI-Domain-Test-Report

С некоторых поря я считаю себя умным человеком. Понимаю, звучит это не очень скромно, но поделать ничего не могу (имеется ввиду,что не могу перестать считать себя умным). Кстати говоря, я себя также считаю еще - скромным. Думаю, это моя вторая замечательная характеристика, как человека.

И поскольку я человек умный, я должен как и всякий умный человек размышлять об умных вещах (подозреваю, что за такие предложения нужно сжигать прилюдно). Я уже упоминал про желание складировать паттерны тестирования в своем блоге . В данной заметке я бы хотел обсудить паттерн построения архитектуры тестовых фреймворков приложений, которому я дал название "GUI-Domain-Test-Report".

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

Проблематика построения тестовых фрейморков приложений

WebDriver: Design Patterns and Development Strategies

Первая ссылка это Design Patterns and Development Strategies . Проект WebDriver должен быть знаком тем, кто занимается автоматизированным тестированим веб-приложений. В документации к данному проекту присутствует описание стратегий-паттернов тестирования.

Остановим внимание на двух:
- DomainDrivenDesign - стратегия, которая предлагает, что работать с веб-приложением ннеобходимо на уровне предметной области (обсудим позже, что такое предметная область приложения).
- PageObjects - стратегия, которая предполагает, что должны быть выделены объекты ответственные за работу со страницами, с которыми вам необходимо работать (обсудим так же позже и подробнее).

GUI-level

В статье компании ATSG упоминаются оконные объекты:
Оконные объекты - этот тип компонентов специфичен для автоматизированного тестирования, в частности GUI-level тестирования и один из наиболее критичных к изменениям тестируемого приложения. Поэтому, для тестирования подобных компонент следует выработать некоторый workflow-сценарий, который затронет все ( или хотя бы просто большинство ) оконных объектов

В статье используется термин GUI-level, которым очень и очень важен для нашего исследовния. Level означает, что существует распределенная архитектура с ярко (или темно) выраженными уровнями-слоями. Вспоминая DomainDrivenDesign (упомянутый ранее), можно выделить также и Domain уровень - уровень предметной области.

Test-Buisiness-GUI

Недавно прошла конференция SQADAYS 2009, на которой мне не удалось побывать. Среди прочих презентаций нам будет очень очень полезна презентация господина Ревко Практические Рекомендации По Организации и Проведению Автоматизированного Тестирования. На странице 11 данной презентации появляется картинка с иерархией различных уровней.

"Для создания тестов, тестируемое приложение нужно разбить на 3 основных уровня:
- Тестовый Уровень
- Бизнес Уровень
- GUI Уровень
2 дополнительных:
- Уровень данных
- Уровень Функций"

Я не согласен с тем, что выделять данные уровни необходимо в тестируемом приложении. На самом деле в тестируемом приложении мы можем выделить уровень бизнес логики и , может быть, GUI уровень, но очевидно автор презентации имел ввиду немного иное. Подозреваю, мысль такова, что упомянутые слои выделяются в тестовом фреймворке приложения - приложении которое создается тестировщиками. Приложении , которое обеспечивает автоматизированное тестирование бизнес приложения.

Далее в презентации идет описание слоев. Опять же, с некоторыми определениями и замечаниями - я не согласен, но останавливаться на этом не буду. В конце концов , это мое личное ошибочное мнение и ругать хорошую презентацию я не хочу.

Фреймворк-тест-драйвер-приложение

В веб-семинаре Алексея Баранцева Автоматизация функционального тестирования приводился пример стека автотестов:

И один из примеров стека автотестов:

В том числе на семинаре были озвучены паттерны тест-дизайна:
- адаптер для всего приложения,
- адаптеры страниц,
- адаптеры частей страниц\блоков,
- репозитарий элементов UI.

Замечание: Алексей просил не выкладывать материалы семинара на общее обозрение, - чего я и не делаю, но делаю небольшую рекламу его презентации и пиарю его курсы - надеюсь мы в расчете ;).

Нам важны данные материалы поскольку на конкретном примере TestNG-Tests-Selenium-Application мы можем понять, как приложение разбивается на слои с использованием существующих продуктов.

Краткое подведение итогов
Собственно, это все материалы, на которых я пытаюсь обосновать свое видение паттерна построения архитектуры тестового фреймворка приложения.

Вполне очевидно что перед нами вырисовывается проблема проектирования тестового фреймворка приложения. Мы видим, что тему построения тестового фреймворка приложения затронута в разных местах, и затронута в одном ключе - разделение архитектуры на слои, отделение мух от котлет, прошу прощения, - GUI от тестов.

GUI-Domain-Test-Report (GDTR)

Как это принято в умных книгах, я приведу краткое описание паттерна:

Наименование: GUI-Domain-Test-Report (GDTR)
Также известен: стратегия построения тестового фреймворка
Тип: системный
Уровень: архитектурный
Назначение: обеспечить создание тестового фреймворка разрабатываемого приложения

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

Паттерн GUI-Domain-Test-Report или в дальнейшем GDTR я бы определил как архитектурный, по той причине, что он связан с построением архитектуры тестового фреймворка приложения.

Еще раз о том, что я вкладываю в термин тестовый фреймворк приложения - это приложение, разработанное для тестирования какого-либо бизнес приложения (или просто приложения).

Паттерн ADTR подразумевает выделение логически разделенных слоев в тестовом фреймворке приложения для обеспечения более гибкой архитектуры. Паттерн включает выделение тех же самых уровней что и в презентации Ревко , но
+ еще один, самый верхний, следующий после тестового - слой формирования отчетности ADTR:REPORT
- один, уровень Функций, который я не понимаю для чего выделять.
- еще один уровень Данных - о котором позже.

GDTR: GUI-ADAPTER
Данный слой предоставляет набор объектов (GUI-ADAPTERS) , озвученных ранее как ObjectAdapter или оконные объекты.

В основе создания данных объектов как я понимаю, лежит использование паттерна проектирования Adapter (он же Wrapper) (http://en.wikipedia.org/wiki/Wrapper_pattern). Любой графический объект (элемент оконной формы) может иметь свой т.н. адаптер для манипуляции с его содержимым в самом тестовом фреймворке.

Я бы выделил следующие графические объекты:
- Элемент (может быть объединен с другими элементами в контейнере формы или более высокого уровня).
В качестве примера графического объекта можно привести: выпадающий список, поле ввода, чекбокс или радиокнопка.

- Форма (может быть объединена с другими формами в общий компонент или страницу).
В качестве примера: вкладка с зависимыми элементами, тег FORM в HTML.

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

- Страница (является контейнером обычных полей, форм, общих компонент) .

Хочу заметить, что я допускаю возможное перемешивание контейнеров: появление общих компонент в формах, страниц в общих компонентах.

Что же входит в обязанности адаптера графических объектов:
- получение данных,
- установка данных,
- клики,
- проверки данных и пр.

В данном слое есть некоторые неприятные моменты. Например для веб-приложений существуют т.н. локаторы, их можно назвать также уникальными идентификаторами графических элементов. Они разные: если используется сложный JavaScript и структура HTML-документа, то всегда возникают проблема - локаторы могут быть разными для:
- кликов,
- получения значения,
- установки значения.

О том как разделять локаторы для различных операций я собираюсь обсудить отдельный паттерн в отдельной заметке.

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

Если переводить слово адаптер на язык программирования, то легче думать об адаптере , как о классе, интерфейс предоставляет методы для манипуляции графическими объектами.

GDTR: DOMAIN-ADAPTER
Данный слой предназначен для того, что бы "беседовать" с приложением на его языке - на языке проблемной области. В этом слое также создаются адаптеры, но уже над графическими адаптерами и для бизнес логики.

В качестве примера можно привести оформление товара в интернет магазине. Для выполнения заказа мы должны:
1. Авторизоваться (адаптер авторизации);
2. Перейти в каталог (адаптер главного меню, адаптер страницы каталога);
3. Перейти выбрать товар (скорее всего адаптер формы товара с ссылкой на товар);
4. Перейти на страницу корзины (адаптер страницы корзины);
5. Оформить заказ (адаптер страницы оформления заказа).

В скобках я указал приблизительные gui-adapter-ы для выполнения операции заказа товара. Данную операцию из 5 шагов может выполнять даже один domain adapter.

Здесь возникает вопрос - могут ли одни адаптеры проблемной области включать другие адаптеры проблемной области? Я считаю, что могут. В противном случае возникает дублирование кода. При усложнении поведения сайта, я бы рассмотрел возможность выделения в отдельный адаптер проблемной области шаги 2 и 3 и еще в один отдельный адаптер шаги 4 и 5. Но тут нужно думать ;)

GDTR: TEST

От тестового уровня требуется одно - провести проверку выполнения бизнес логики приложения. Используя адаптеры уровня проблемной области выполняются определенные тестовые шаги с последующей проверкой (сравнение с существующим эталоном, например).

Я бы назвал данный уровень модульным тестированием результатов работы адаптеров более низких уровней. Тестовые объекты проверяют и отваливаются с ошибкой, либо отрабатывают успешно. О модульном тестировании, использовании тестовых фреймворков, думаю, в данной заметке особо распространяться не стоит.

В качестве примера можно привести оформление заказа товара, с последующей проверкой - отразилась ли информация о товаре (количество и сумма) на странице "Корзина".

GDTR: REPORT
Я выделил данный уровень в отдельный, поскольку получение отчетов о тестах, как мне кажется, должно быть выделено из уровня тестов. Сделать это необходимо хотя бы потому, что отчеты могут быть представлены в разных форматах, с разной детализацией содержать разные данные - т.е. быть вообще разными.

На практике тестовый уровень и уровень формирования отчетов о проведенных тестах могут встречаться в одном фреймворке (например TestNG формирует отчетность в HTML формате, зеленым цветом выделяются прошедшие тесты, красным - не прошедшие.)

Заключение

Надеюсь, что в моей заметке есть и новое и занятное, (да бог чтобы не было такой ситуации когда новое не занятное, занятное не новое) и даже неправильное. К сожалению я не присутствовал на SQADays 2009 и не знаю как обсуждалась презентация господина Ревко. Очень бы хотелось, но не получилось. Думаю результаты обсуждения могли бы серьезно повлиять на содержание данной заметки.

Конечно же многое еще не раскрыто. Есть еще вопросы, которые следует обдумать:
- Вопросы именования объектов слоев. Весьма спорный вопрос. Например, именовать все тестовые объекты начиная с префикса Test. Я лично против такой обязательности. Но в JUnit так принято (а вот в TestNG - нет).

- Проблема разделения данных между слоями. В презентации господина Ревко есть слой, Данных, растянутый между центральными. Я пока не готов рассуждать, как его разделить между упомянутыми мной слоями паттерна GDTR.

- Проблема отделения локаторов графических элементов от их поведения - в литературе используется термин GUI mapping. Я упомянул проблему в заметке. Дай бог разумения понять, как это делается.

Надеюсь, что замечания по паттерну скоро поступят, и я подправлю данную заметку.

Замечания принимаются и обсуждаются.