Данная статья не содержит в себе практических примеров. Тут можно найти общее описание Page Object Pattern'a, основные концепции, которые он в себе реализует и причины его возникновения. Для более глубокого понимания материала, читатель должен иметь представление об автоматизации web-приложений, программировании и ООП.
Автоматизация тестирования web-приложений чаще всего ассоциируется с инструментом Selenium. Это случилось не просто так... Селениум получил заслуженное признание благодаря своей простоте, поддержке основных браузеров, большому сообществу пользователей, более того, тесты могут использовать ряд популярных языков программирования: Java, C#, Ruby...
Если мы говорим о написании реальных авто-тестов, то нужно заметить, что можно это делать разными путями.
Selenium IDE. С помощью этого плагина можно легко записывать последовательность действий, которую вы выполняете в ручном режиме в браузере. Далее вы получаете готовый тест, который можно немного подправить ручками и положить в общую копилку. Под словами "подправить ручками" я имею ввиду внесение правок в локаторы, условия проверок и т.д.
В результате написания ряда таких тестов, образуется множество "простыней" с набором последовательных действий. Шаблон каждого теста примерно такой:
Selenium RC. Тут дела обстоят веселее. Подключаете библиотеку селениума к вашему проекту в любой IDE (я использую Eclipse) и начинаете набивать код. В итоге будет получаться нечто подобное, как и в варианте с Selenium IDE, все также будут 3 компонента, но за счет того, что тут используется напрямую языки программирования, можно делать более насыщенной логику теста.
А что если?
Представьте, что вы каким-то образом использовали одну из выше озвученных техник для автоматизации своего проекта. Допустим у вас есть 10 тестов для проекта. И внезапно наступает момент, когда вы переезжаете на новый домен, тогда нужно будет в каждом тесте менять отправную точку для теста. Возможен вариант, что был изменена верстка сайта и тогда по всем тестам нужно будет менять локаторы. К примеру в ваших тестах есть действия, которые пересекаются между собой (такое бывает, когда тесты нацелены на одну зону функциональности), в таком случае вам придется копировать от теста к тесту куски кода, которые будут повторяться и увеличивать объем кода.
Подобно тому, как процедурное программирование было оттеснено объектно-ориентированным подходом, так и автоматизация тестирования пошла путем эволюции.
Page Object Pattern. Данный шаблон для построения фреймворка очень логичен и практичен. Следует начать с того, что каждый тест начинается одинаковым образом - открывается браузер, загружается стартовая страница сайта. Кстати заканчивается любой тест закрытием браузера. И уже на этом этапе подключается наследование для тестов. Создается родительский тест в который внедряются все общие действия.
Что касается логики тестов, то тут следует заметить, что все множество тестов содержит в себе повторы одних и тех же действий. Какие-то из них встречаются чаще (к примеру, переход на домашнюю страницу сайта), какие-то реже (к примеру, переход на страницу обратной связи), но факт остается один - они повторяются. Исходя из этого, становится логичным создание иерархии страниц сайта по их типу: BasePage, CategoryPage, MyAccountPage, ...
Каждый класс страницы будет содержать в себе исключительно те элементы и действия с ними, которые характерны для данного типа страниц на реальном сайте. Но существует множество активностей, которые мы можем выполнять вне зависимости от того на какой странице мы находимся. К примеру, мы можем использовать поиск на сайтах с любой страницы, можем кликнуть по логотипу сайта на любой странице... Это является основной причиной создания базового, родительского класса, от которого будут наследоваться все последующие классы страниц для того, чтобы перенять все его свойства и методы.
Как результат, получаем 2 ветки наследования:
Автоматизация тестирования web-приложений чаще всего ассоциируется с инструментом Selenium. Это случилось не просто так... Селениум получил заслуженное признание благодаря своей простоте, поддержке основных браузеров, большому сообществу пользователей, более того, тесты могут использовать ряд популярных языков программирования: Java, C#, Ruby...
Если мы говорим о написании реальных авто-тестов, то нужно заметить, что можно это делать разными путями.
Selenium IDE. С помощью этого плагина можно легко записывать последовательность действий, которую вы выполняете в ручном режиме в браузере. Далее вы получаете готовый тест, который можно немного подправить ручками и положить в общую копилку. Под словами "подправить ручками" я имею ввиду внесение правок в локаторы, условия проверок и т.д.
В результате написания ряда таких тестов, образуется множество "простыней" с набором последовательных действий. Шаблон каждого теста примерно такой:
- WebElement - любой элемент на странице, с которым нужно произвести взаимодействие.
- Action - действие, которое можно произвести с элементом на html страничке: кликнуть, выбрать, и т.д.
- Assert - проверка результата, к примеру на наличие текста в определенном элементе.
Selenium RC. Тут дела обстоят веселее. Подключаете библиотеку селениума к вашему проекту в любой IDE (я использую Eclipse) и начинаете набивать код. В итоге будет получаться нечто подобное, как и в варианте с Selenium IDE, все также будут 3 компонента, но за счет того, что тут используется напрямую языки программирования, можно делать более насыщенной логику теста.
А что если?
Представьте, что вы каким-то образом использовали одну из выше озвученных техник для автоматизации своего проекта. Допустим у вас есть 10 тестов для проекта. И внезапно наступает момент, когда вы переезжаете на новый домен, тогда нужно будет в каждом тесте менять отправную точку для теста. Возможен вариант, что был изменена верстка сайта и тогда по всем тестам нужно будет менять локаторы. К примеру в ваших тестах есть действия, которые пересекаются между собой (такое бывает, когда тесты нацелены на одну зону функциональности), в таком случае вам придется копировать от теста к тесту куски кода, которые будут повторяться и увеличивать объем кода.
Подобно тому, как процедурное программирование было оттеснено объектно-ориентированным подходом, так и автоматизация тестирования пошла путем эволюции.
Page Object Pattern. Данный шаблон для построения фреймворка очень логичен и практичен. Следует начать с того, что каждый тест начинается одинаковым образом - открывается браузер, загружается стартовая страница сайта. Кстати заканчивается любой тест закрытием браузера. И уже на этом этапе подключается наследование для тестов. Создается родительский тест в который внедряются все общие действия.
Что касается логики тестов, то тут следует заметить, что все множество тестов содержит в себе повторы одних и тех же действий. Какие-то из них встречаются чаще (к примеру, переход на домашнюю страницу сайта), какие-то реже (к примеру, переход на страницу обратной связи), но факт остается один - они повторяются. Исходя из этого, становится логичным создание иерархии страниц сайта по их типу: BasePage, CategoryPage, MyAccountPage, ...
Каждый класс страницы будет содержать в себе исключительно те элементы и действия с ними, которые характерны для данного типа страниц на реальном сайте. Но существует множество активностей, которые мы можем выполнять вне зависимости от того на какой странице мы находимся. К примеру, мы можем использовать поиск на сайтах с любой страницы, можем кликнуть по логотипу сайта на любой странице... Это является основной причиной создания базового, родительского класса, от которого будут наследоваться все последующие классы страниц для того, чтобы перенять все его свойства и методы.
Как результат, получаем 2 ветки наследования:
- Для тестов
- Для страниц
Комментариев нет:
Отправить комментарий