Эта статья является продолжением SpiderTest: Автотесты своими руками. Однако, первая часть обзора на это приложение была больше ориентирована на десктопный интерфейс. В этой же хотелось бы поговорить об экзотике: связи тестов с CI-server’ом и GitHub.
Может возникнуть вопрос: «Зачем вообще все это нужно? Мы написали тест, прогнали его в нужных браузерах и нам достаточно» и в целом он довольно обоснованный! Действительно, для обычного тестирования, запуска автотестов из самого приложения SpiderTest в большинстве случаев бывает достаточно. Но что делать, если мы хотим запустить тесты в IE9-11, Opera, FireFox и Google Chrome разных версий? На одной машине это сделать невозможно, а создавать кучу виртуальных машин и запускать по очереди в каждой утомительно (и вообще это костыль).
А если мы хотим провести дымовое тестирование? Или хотим запускать тесты не только в разных браузерах, но и в разных операционных системах (Windows OS, Linux OS)?
Самый оптимальный ответ на поставленные выше вопросы – использовать сервер непрерывной интеграции. В этой статье я рассмотрю настройку SpiderTest и Jenkins. Справедливости ради стоит сказать, что запускать тесты можно и на bamboo, и на teamcity, но Jenkins прост и бесплатен, поэтому рассмотрим его.

Конфигурирование Jenkins для Windows OSи Linux OS.

Прежде чем начинать работу нужно установить дистрибутив Jenkins, скачать Apache Maven Project, JDK 7 и Git и прописать их в системных переменных.
Теперь можно приступать к настройке Jenkins. И первое, с чего начнем – установим нужные плагины.



Для этого нужно перейти в «Настроить Jenkins» (1), а затем в «Управление плагинами» (2).
• GitHub plugin – плагин для работы с GitHub
• JUnit Plugin – плагин для запуска модульных тестов
• Allure Jenkins Plugin – яндексовский плагин для создания отчетов.
После установки нужно перезапустить сервер, это можно сделать, введя localhost:8080/restart, в адресной строке.
Затем переходим в «Конфигурирование системы» (3). В открывшемся окне заполняем блоки «Git», «Jenkins Location» и «Allure Plugin».
Следует указать два «Git installations» для WindowsOS и LinuxOS, лучше сделать как на скриншоте.



Так же не лишним будет прописать «Jenkins Location» чтобы была возможность заходить в Jenkins извне.



И, наконец, заполнить «Allure Plugin»



После конфигурирования нужно еще раз перезапустить сервер.

Система контроля версий Git

Чтобы тестирование было совсем серьезным, как у суровых программистов, не лишним для команды тестировщиков использовать систему контроля версий. Не мне объяснять, что «система контроля версий отнимает времени самую малость, зато пользы от него цельный вагон» (с) Коровьев «Мастер и Маргарита».
В общем создаем профиль на гитхабе и закидываем туда следующие файлы из тех, что лежат в папке SpiderTest:
• Config – папка в которой указаны настройки, хранятся списки шагов и элементов
• Data – папка с шаблонами классов, методов maven-проекта
• Lib – папка с библиотекой SpiderTestCILib.jar
• Add-lib.bat – исполняемый файл, который добавляет библиотеки в локальный репозиторий maven
• Add-lib.sh – то же самое, но для LinuxOS.
• SpiderTestCI.jar – Jar-ник, который создает maven-проект.
• Start-test.bat – исполняемый файл, который запускает SpiderTestCI.jar.
• Start-test.sh — то же самое, но для LinuxOS.
• TestKit – папка с автотестами.

Вот о SpiderTestCI.jar хотелось бы сказать пару слов отдельно, но чуть позже.

Создание плана сборки тестов

После того как Jenkins CI конфигурирован, можно приступать к созданию плана сборки.



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



Git executable выберем «по умолчанию» Windows. И начнем добавлять шаги сборки.





Первым шагом в создании плана сборки будет добавление библиотеки в локальный репозиторий maven, выполнив add-lib.bat (либо add-lib.sh в LinuxOS).

Вторым шагом будет создание maven-проекта сборки и запуск тестов. Для этого нужно выполнить start-test.bat [arg] (или start-test.sh [arg]), где [arg] – это путь до файла, либо путь до папки с тестами.



И, наконец, добавить послесборочный шаг Allure Jenkins Plugin с указанием версии отчета.



Теперь осталось всего-то выполнить сборку, нажав «Собрать сейчас».



Первая сборка будет довольно долгой, из-за скачивания зависимостей проекта. Историю сборок и отчет можно посмотреть здесь.



Спонсором красивого отчета стал Яндексовский плагин Allure Plugin более подробно о нем написано здесь



Алгоритм работы SpiderTestCI.jar

Выполняя start-test.bat, SpiderTestCI.jar проверяет что ему передали в качестве аргумента: файл или папку с файлами. Если передали папку, то он ищет в ней файлы с расширением .sff (в папке должны быть только файлы теста в расширении .sff иначе джарник будет ругаться). Итак, SpiderTestCI.jar считывает файл теста, находит часто используемые шаги и элементы и подтягивает их из config\namespaces\, затем из файла config\config.cfg считывает путь до браузеров (в случае если они указаны), после этого смотрит переменные (если они указаны), затем считывает шаблоны maven-проекта из папки data и, наконец, на выходе получаем maven-проект с уже готовыми к запуску тестами, который состоит из трех объектов:
• environment.xml
• pom.xml
• директория src

Настройка сборщика на LinuxOS

Теперь настроим еще одного сборщика-раба чтобы запускать тесты на LinuxOS.
Прежде чем начинать конфигурировать еще одного сборщика, необходимо сделать некоторые предустановки на линуксовой машине. А именно:
• JDK7 – чтобы Jar-ники воспринимать.
• Git – чтобы Linux умел брать исходники с гитхаба.

sudo apt-get install git

Нелишним будет проверить, что git прописался в системных переменных для этого нужно в командной строке ввести git. Появилось много текста? Замечательно)
• SSH-клиент, чтобы Jenkins смог подключиться к своему сборщику по протоколу ssh.

sudo apt-get install openssh-client
sudo apt-get install openssh-server

• slave.jar – jar-ник, запускаемый дженкинсом на машине «раба»
Его можно скачать, введя localhost:8080/jnlpJars/slave.jar
Затем скинуть его в папку, например \home\user\slave и дать все права на папку типа

chmod –R 777

И вот только теперь можно в Jenkins настраивать новый узел.



Ввести настройки доступа по ssh. Следует удостовериться, что к виртуалке можно подключиться извне, например, с помощью Putty. Кстати, стоит давать адекватное имя сборщику, чтобы при переключении с одного на другой правильно идентифицировать.



Затем включить подчиненный узел к мастеру. Включаться новый сборщик первый раз будет так же долго, как и «мастер». Дело все в тех же библиотеках maven.



Чтобы запустить сборку на LinuxOS нужно сделать следующие действия:
1. В настройках плана сборки выбрать исполнителя (машина на которой развернут Jenkins – master, а названия всех сборщиков задаем самостоятельно).



2. Переключиться между сборщиками в блоке «Управление исходным кодом».



3. Исправить в плане сборки команды так, чтобы были задействованы линуксовые исполняемые файлы:



И вновь запустить сборку. Не лишним будет упомянуть, что на виртуальных машинах должны быть установлены все браузеры, которые используем в тестах и драйвера этих браузеров прописаны в системных переменных.
Эта статья завершает обзор инструмента SpiderTest, но это не значит, что он остановится в своем развитии. Нужно больше людей, которые будут использовать SpiderTest, чтобы продвинуть приложение на новый уровень. Подписывайтесь на новые версии, комментируйте, предлагайте.

P.S. С выпуска предыдущей статьи уже вышло 3 версии SpiderTest. Последняя версия 1.1.1 уже доступна для скачивания. Следующий релиз не за горами и в нем будут дополнения, которые вы добавляете в комментарии.
P.P.S практика показала, что нужно очень осознанно использовать списки шагов и элементов. Они сохраняются в специальную папку «config/namespaces» и если вы удаляете/переносите или как-то изменяете файлы из папки namespaces, то тесты, использующие их, не будут выполняться. Так что просьба быть внимательнее.