1) Генерация XML файла с результатами выполнения теста
- убедиться, что установлен NUnit версии 2.6.3 (внимание, это важно, так как с версией 2.6.4 allure На текущий момент не работает), если нет – скачать отсюда - http://www.nunit.org/index.php?p=download и установить
- скачать последний релизный allure адаптер для NUnit - https://github.com/allure-framework/allure-nunit/releases
- распаковать скачанный архив в %NUnit_installation_directory%\bin\addins (например - C:\Program Files (x86)\NUnit 2.6.3\bin\addins)
- в файле конфигурации config.xml в параметре <results-path> указать путь до папки, в которую будут складываться результаты выполнения теста (также в файле конфигурации можно указать необходимость создания скриншотов)
- выполнить тесты в NUnit GUI или в консоли nunit-console, используя.NET 4.0 (например, nunit-console YourAssembly.dll /framework=net-4.0)
- после того, как завершится исполнение тестов файл создастся в папке, указанной ранее в параметре <results-path>
2) Получение отчета из сгенерированного xml файла
- скачать последнюю версию allure-cli отсюда - https://github.com/allure-framework/allure-cli/releases/tag/allure-cli-2.3
- установите jdk - http://www.oracle.com/technetwork/java/javase/downloads/index.html
- создайте новую системную переменную JAVA_HOME, указывающую на папку с установленным jdk, например - C:\Progra~1\Java\jdk1.8.0_31 (подробно процесс создания новой переменной описан здесь - https://confluence.atlassian.com/display/DOC/Setting+the+JAVA_HOME+Variable+in+Windows)
- распаковать архив в папку с названием allure-cli
- перейти в папку bin, создать в ней исполняемый файл run.cmd, состоящий из следующих команд:
allure.bat generate -v 1.4.1 D:\test-results-allure\
pause
вместо D:\test-results-allure\ необходимо указать свой путь до папки с xml файлами, сгенерированными на первом шаге
- запустите run.cmd
- после его выполнения в папке bin создастся папка allure-report, содержащая файл index.html, который и является страницей отчета
Шаблон проектирования “Page Object”
Основная идея паттерна Page Objects инкапсулировать логику поведения страницы в классе страницы. Таким образом, тесты будут работать не с низкоуровневым кодом технического драйвера, а с высокоуровневой абстракцией.
Основные преимущества Page Objects:
1. Разделение полномочий: вся «бизнес-логика» страницы должна помещаться в Page Objects, классы тестов лишь вызывают публичные методы и проверяют результат
2. DRY – все локаторы помещаются в одном месте. Когда UI изменится, то мы изменим локатор лишь в одном месте
3. Скрытие слоя технического драйвера. Тесты будут работать с высокоуровневой абстракцией. В будущем, возможно, вы захотите сменить драйвер: например, использовать PhantomJS, или вообще для каких-то участков отказаться от использования WebDriver, для улучшения производительности. В этом случае, придется заменить только код Page Objects. Тесты останутся неизменными
4. Page Objects позволяет записать локаторы в декларативном стиле
За основу реализации в проекте взята данная статья - http://habrahabr.ru/post/155109/ Пример реализации проекта по данной статье доступен по ссылке - https://github.com/DmitryRoss/Page-Object-Model-Article
Обязательные составляющие проекта:
- класс BaseObject, в котором инициализируются страницы:
public class BaseObject
{
public static RemoteWebDriver Driver;
public static DefaultSelenium Selenium;
public static void InitPage<T>(T pageClass) where T: BaseObject
{
PageFactory.InitElements(Driver, pageClass);
}
}
- класс BaseTest, который наследуется от BaseObject. В нем объявляются блоки TestFixtureSetUp, TestFixtureTearDown, SetUp, TearDown. В TestFixtureSetUp объявляется соответствующий драйвер и его настройки, в TestFixtureTearDown осуществляется закрытие драйвера, в SetUp – переход на главную страницу системы, в TearDown – проверка страницы на наличие ошибок, а также проверка на наличие ошибок в консоли.
- в классе Utils (также наследуется от BaseObject) – содержатся функции и переменные, общие для всех страниц системы, например - адреса определенных страниц, а также служебные функции (функция ожидания)
Для тестирования страницы создаются следующие классы (на примере тестирования входа в систему):
1) Класс с описанием самих элементов страницы – LoginPage (наследуется от BaseObject)
Структура данного класса следующая:
- локаторы страницы: public const string USER_NAME_TEXT_FIELD = "//input[@id='login']";
- объявление соответствующего веб=элемента для локатора:
[FindsBy(How = How.XPath, Using = USER_NAME_TEXT_FIELD)]
public IWebElement userNameTextField;
- функция инициализации данной страницы:
public static LoginPage GetLoginPage()
{
LoginPage loginPage = new LoginPage();
InitPage(loginPage);
return loginPage;
}
- функции работы с элементами страницы:
public LoginPage TypeUserName(string userName)
{
userNameTextField.SendKeys(userName);
return GetLoginPage();
}
2) Класс помощник helper (Каждый такой класс обслуживает один конкретный класс с тестами) - LoginHelper
Структура класса:
- инициализация страницы(страниц):
private LoginPage loginPage = new LoginPage();
- функции, обращающиеся к элементам страницы:
public LoginHelper DoLogin(string userName, string password)
{
BaseObject.InitPage(loginPage);
loginPage.LogOff().
TypeUserName(userName).
TypePassword(password).
ClickLoginButton();
return this;
}
3) Класс теста – LoginTest
Структура:
- инициализация helper’а:
private static LoginHelper loginHelper = new LoginHelper();
- сам тест (он состоит из обращений к функциям helper’а):
[Test]
public static void AssertLogin()
{
string userName = "admin";
string password = "";
string displayedUserName = "Администратор";
string Welcome_text = "Добро пожаловать в систему ELMA!";
loginHelper.
DoLogin(userName, password).
AssertUserName(displayedUserName).
AssertHomePage(Welcome_text);
}
4) Класс со вспомогательными функциями (используемыми только для данной страницы, общие вспомогательные функции объявляются в Utils) - LoginUtils
