Ядро фреймворка объединяет все те средства, которые необходимы для реализации тестов, такие как: работа с веб драйверами, реализация паттерна Page Object, взаимодействия для тестирования Api, генерация данных, чтение конфигурации запуска. Для наиболее простого развёртывания используйте коробочную версию Banjo. В данном кратком руководстве по использованию будет рассказано о подключении данного ядра, а так же вспомогательных библиотек, не включённых в ядро для большей свободы выбора тестового фреймворка, фреймворков отчётности, логгеров и т.п.
При навигации по страницам следует следить за контекстом -- текущем блоком или страницей, внутри которого ищется запрашиваемый шагом элемент. Это значительно облегчает понимание с каким именно элементом происходит работа.
В связи с этой особенностью нужно явно задавать блочный элемент при помощи метода в AbstractFrameworkSteps#setCurrentBlock, внутри которого происходит дальнейшая работа (блочный элемент, наследник AbstractBlockElement или AbstractMobileBlockElement) и так же явно его освобождать при переходе к следующему блоку при помощи AbstractFrameworkSteps#resetCurrentBlock. Таким образом контекст поиска вернётся к текущей странице. Если предварительно контекст поиска не был освобождён, то поиск будет вестись внутри текущего блока и в случае успеха текущим станет найденный блок.
Текущей страницей является последняя запрошенная страница.
Кэш ранее запрошенных страниц. Позволяет сократить время на инициализацию страниц. В связи с этим именно PageCatalog является точкой входа для инициализации (запроса) новых страниц.
Особое внимание следует уделить, что при запросе страницы не происходит переход на её url, а только инициализируется PageObject с прокси-объектами страницы. Конкретный поиск и получение элемента происходят в момент работы с конечным элементом.
Вспомогательный утилитарный класс для генерации различных тестовых данных. В качестве примера рекомендуется реализация из коробочного фреймворка, где создание тестовых данных происходит при помощи механизма TypeRegistry Cucumber. Возможны и другие примеры реализации.
Реализована генерация:
- адресов
- дат, в том числе относительных
- файлов (иммитация формата только на уровне заголовка и расширения)
- чисел
- персональных данных: паспорт, свидетельство о рождении, ИНН и т.п.
- строковых данных
Для простоты обращения к элементу из Gherkin сценария его можно находить в странице и блочном элементе так же по произвольному имени, заданному при помощи аннотации @WithName и метода AbstractFrameworkSteps#getElementByName. Аналогичный механизм предусмотрен для нахождения страницы при помощи библиотеки Reflections. Для этого интерфейс страницы помечается аннотацией @Title и вызывается метод AbstractFrameworkSteps#getPageByTitle.
Добавьте в зависимости к своему maven-проекту
<dependency>
<groupId>com.github.lanit-izh</groupId>
<artifactId>automation-framework-core</artifactId>
<version>4.0.9</version>
</dependency>или gradle-проекту:
repositories {
mavenCentral()
maven { url "https://jitpack.io" }
}
dependencies {
compile("com.github.lanit-izh:automation-framework-core:4.0.9")
}Для работы так же потребуются дополнительные зависимости, которые могут отличаться от ваших предпочтений. Для примера мы используем Cucumber TestNG для запуска тестов и Allure для отчётности:
<dependency>
<groupId>io.cucumber</groupId>
<artifactId>cucumber-testng</artifactId>
<version>4.2.4</version>
</dependency>
<dependency>
<groupId>io.qameta.allure</groupId>
<artifactId>allure-cucumber4-jvm</artifactId>
<version>2.12.1</version>
</dependency>то же для gradle
compile 'io.cucumber:cucumber-testng:4.2.4'
compile 'io.qameta.allure:allure-cucumber4-jvm:2.12.1'Создайте TestNG-раннер для фреймворка в test/java:
@CucumberOptions(
plugin = {"pretty",
"io.qameta.allure.cucumber4jvm.AllureCucumber4Jvm",
"json:target/cucumber.json",
},
glue = {"steps", "hooks"},
features = "classpath:features"
)
public class TestsRunner extends AbstractTestNGCucumberTests {
}В пакете test создайте подпакеты steps и hooks. В пакете test.steps будут сохраняться имплементации шагов Cucumber. В пакете test.hooks различные настроечные шаги, например шаги перед сценарием или регистрация TypeRegistry.
В пакете test.hooks создайте при необходимости файл с хуками кукумбера. Чтобы получить доступ ко всем встроенным методам, наследуйте его от AbstractFrameworkSteps. В примере ниже используются включённые в коробочную версию фреймворка утилитарные классы и расширения Atlas.
@Before
public void setUp() {
// здесь подключаются расширения Atlas. Подробнее о них в проекте https://github.com/qameta/atlas
Atlas atlas = getAtlas();
atlas.extension(new ElementReadyClickSendKeysExtension());
atlas.extension(new IsDisplayedExtension());
}
@After
public void tearDown(Scenario scenario) {
if (driverIsActive()) { // прикрепляем финальный скриншот страницы к отчёту. AllureHelper доступен в коробочной версии фреймворка
AllureHelper.attachPageSource(getDriver().getPageSource().getBytes(StandardCharsets.UTF_8));
AllureHelper.attachScreenShot("Скриншот последней операции", getScreenShooter().takeScreenshot());
shutdownDriver();
}
// Если используется citrus для тестирования api
MessageTracingTestListener messageTracingTestListener = (MessageTracingTestListener) getEndpointByName("messageTracingTestListener");
messageTracingTestListener.onTestFinish(getCitrusRunner().getTestCase());
// вывод софт-ассёртов. В коробочной версии реализовано на базе ExtendedAssert TestNG
softAssert().assertAll();
softAssert().flush();
}Для создания страницы небходимо создать интерфейс в папке main/java/pages и отнаследовать интерфейс от AbstractPage для web-страниц, или от AbstractScreen для экранов мобильных приложений:
@Title("Стартовая страница Google")
public interface GoogleStartPage extends AbstractPage {
@Override
default boolean isOpen() {
return getWrappedDriver().getCurrentUrl().matches("https?://(?:www.)?google\\.com/?.*");
}
@WithName("Поиск")
@FindBy("descendant::input[@title='Поиск']")
Input searchField();
}Полностью пример доступен в коробочной версии.
Создание страниц-объектов можно посмотреть в коробочной версии фреймворка. Для упрощения реализации шагов рекомендуется придерживаться ряда правил:
- типы элементов, встречающиеся только на этой странице, должны храниться в пакете этой страницы
- рекомендуется давать конкретные и исчерпывающие названия страницы в аннотации
@Title - методы по работе с элементами страницы рекомендуется создавать внутри страницы, но если эти методы характерны для блока, который используется на нескольких страницах, логику лучше перенести в него.
- PageObject используется как абстракция "физической" страницы, однако в зависимости от контекста одной странице может соответствовать несколько PageObjects
- для максимального переиспользования элементы необходимо именовать при помощи аннотации
@WithName, либо максимально унифицировать локатор, чтобы он подпадал под все вариации типа элемента
Определения шагов создаются в папке test/java/steps, но это зависит от параметров, которые были указаны в настройках Cucumber.
Непосредственно создание шагов удобнее всего делать после создания feature-файла при помощи средств генерации плагина Cucumber, например для Intellij Idea. Однако, следует получившийся stepDefinition-класс наследовать от AbstractFrameworkSteps или от AbstractFrameworkAndroidSteps, это даст доступ к модулям ядра без дополнительных усилий.
Рекомендуется группировать реализации шагов по конечным элементам взаимодействия. Таким образом будет проще отслеживать дубликаты и разрешать конфликты.
Если вам плохо знаком BDD подход, рекомендуется вначале ознакомиться с общими подходами. Подойдёт эта статья.
Для начала создайте feature-файл в test/resources/features/. Для Intellij Idea понадобится плагин Cucumber for Java.
Рекомендуется придерживаться следующих правил при создании шагов:
- шаги начинаются с маленькой буквы
- строковые значения передаются в двойных кавычках, цифровые -- без
- шаги типизированы. То есть шаг подходит для всех элементов, логически поддерживающих данное действие, то он и должен работать со всеми элементами. Например, кликнуть на элемент "Блок предпросмотра" должен совершать клик по любому типу элементов, на которые только можно кликнуть. В то же время, если шаг ограничен типом в поле "Поиск" ввести "1+1=", такой шаг будет искать только типы, наследуемые от типа поле (в коробочной версии фреймворка это элементы типа Field), но никак не выпадающие списки или кнопки.
- формулировка шагов должна явно указывать на тип действия:
- шаги, содержащие проверки assert должны быть в утвердительной форме: открыта страница "Поиск Google" и в случае ошибки должны выбрасывать соответствующую ошибку
- шаги, выполняющие действие, должны формулироваться в виде действия: нажать кнопку "Поиск"
- не нужно вводить лишние слова, знаки препинания и прочие выражения, могущие создать дублирование формулировок. Например, вместо нажать на основную кнопку "Поиск" следует ограничиться нажать кнопку "Основная кнопка Поиск", либо вообще не указывать тип там где это не нужно для ограничения по наследованию: нажать "Основная кнопка Поиск"
Для запуска тестов нужно использовать maven. В зависимости от тестового фреймворка и версии Cucumber, команда запуска может отличаться. В нашем случае с зависимостью от TestNG и CucumberTestNG запуск будет происходить через кукумберовский раннер:
mvn test -Dcucumber.options='--tags @GoogleCalc'Соответствующим образом конфигурируется запуск в Jenkins или другой CI/CD.