Локальный запуск ui-тестов на машине разработчиков

инфраструктура
, , ,
#1

Есть задача запуска быстрых смок-тестов UI локально на машинах фронтэнд-разработчиков по требованию. Такова особенность конкретного проекта. Тесты должны запускаться у конечного пользователя быстро и удобно, легко обновляться, время прохождения смок-тестов не более 5 минут.

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

Я вижу два варианта:
Запуск готового монолитного jar-файла у пользователя через батник. Предварительно в код тестов добавить метод Main, который будет TestNG запускать и прокидывать для него аргументы из командной строки (чтобы каждому не ставить мавен):

public static void main(String[] args) { 
org.testng.TestNG.main(args); }

Отсюда - selenium webdriver - how to call testng.xml from java main method? - Stack Overflow
Батник предварительно выполнит проверку версии jar-файла в сетевом хранилище. И запустит - java -jar yourjar.jar -testclass org.test.xyz.java или java -jar yourjar.jar testng.xml
Что смущает: Нет опыта создания монолитного jar файла. Как?

Второй вариант – Jenkins. ПК программистов подключить как ноды. Запуск тестов через джобу.
Что смущает:

  1. Сначала придется руками подключать каждый ПК в роли ноды.
  2. Для каждой ноды создать свою джобу Т.к. ряд параметров для запуска тестов могут быть у разных разработчиков свои (ну и нода для запуска – свой ПК), нужно будет создавать для каждого параметры по умолчанию, чтобы запуск был по одному клику. Если нужно будет обновить общие параметры запуска джоб, придется каждую отдельно редактировать. Так?
  3. Jenkins нужно связать с ActiveDirectory компании (через LDAP плагин?), чтобы каждый пользователь заходил под своей учеткой и мог запустить только свою джобу.

Если обозначенные проблемы относительно Jenkins легко решаются, то я склоняюсь ко второму варианту – он позволит централизованно управлять всем процессом и заодно прокачать свои навыки по Jenkins ))

Посоветуйте пожалуйста, какой подход лучше использовать или предложите другой. Спасибо.

#2

Ну оооочень странные требования! Сейчас же не каменный век, нужно ощаться и настраивать процесс правильно. НУ если же не так, тогда докер вам в помощь, запаковывайте все в докер и пуская разработчики запускают образы

#3

Система очень старая, бэк для фронта используется в готовом виде. Unit-тестов на фронте почти нет, архитектура запутанная, поэтому сейчас, внеся какие-то изменения в код, перед пулреквестом в девелоп-ветку, разработчики локально руками проверяют работоспсобность не только напрямую затронутого функционала, но и все что “рядом”.
Распишите пожалуйста подробней про то, что вы имеете в виду про запаковку в докер?.. не представляю как автотесты потом из докера запускать )) (если вы про это)

#4

А в чем проблема сделать отдельную джобу для фича-бранчей, в которой будут запускаться смок-тесты по коммитам. И не надо будет городить своего огорода. И как показывает практика разработчики всё равно будут забывать запускать тесты, и тем более заставлять их че-то устанавливать и запускать дополнительно -это такое себе, и потом еще учить их анализировать тест резалты, а так всё будет автоматом.

2 лайка
#5

Я всегда агитирую как раз за то, что разработчики должны иметь возможность сами запускать автотесты. Я сам разработчик, и мы их запускаем постоянно. Более того, даже пишем.

Вы правда думаете, что для разработчиков поставить мавен - проблема? Серьёзно? Это ж разработчики, они кучу разных тулов себе ставят. Да и мавен у них наверняка уже есть.

Однозначно, идите самым простым первым путём, и не вздумайте усложнять.

3 лайка
#6

нужно использовать градл, тогда и ставить ничего не нужно :wink:

2 лайка
#7

[quote=“Valentin_Buryakov, post:4, topic:12577, full:true”]
в чем проблема сделать отдельную джобу для фича-бранчей, в которой будут запускаться смок-тесты по коммитам. [/quote]
да, это абсолютно правильный подход, но если так можно было сделать, я бы не создавал этот топик, но это относится к “Особенностям проекта”.

И как показывает практика разработчики всё равно будут забывать запускать тесты, и тем более заставлять их че-то устанавливать и запускать дополнительно -это такое себе

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

#8

ну а как конкретно, исходя из моих задач? :slight_smile:

#9

Точно так же как и мавен, только ставить ничего не нужно. Да и перевести проект с мавена на грейдл дело не сильно сложное.

Gradle это тоже билд тул, но модерный, сочетает в себе простоту ant и мощность maven. В качестве конфига, вместо XML использует Groovy, из-за чего конфиги получаются более понятными, короткими и гибко настраиваемыми.

Например самый базовый конфиг для селениум тестов:

group 'ysparrow.ua'
version '1.0-SNAPSHOT'

apply plugin: 'java'

sourceCompatibility = 1.8

repositories {
    mavenCentral()
}

dependencies {
    testCompile group: 'junit', name: 'junit', version: '4.11'
    testCompile 'org.seleniumhq.selenium:selenium-java:3.0.1'
    testCompile 'io.github.bonigarcia:webdrivermanager:1.5.1'
}

Это в разы короче чем мавен. Плюс структура проекта точно такая же… ничего вообще менять в общем случае не нужно.

Ну и самое главное, в грейдл проекте есть так называемый gradle-wrapper который являет собой джарник грейдла, и позволяет запускать билд на любой машине, даже если там сам грейдл не установлен.

То есть, вместо mvn clean test пишите gradlew clean test и при этом не надо ничего дополнительно инсталить.

3 лайка
#10

спасибо за ваш развернутый ответ

Да, миграция на gradle очень простая, достаточно в корне проекта выполнить
gradle init
https://gradle.org/migrating-from-maven

Тесты прекрасно работают, в т.ч. через враппер.

Но, задача создания единого jar файла проекта осталось актуальной, т.к. оказалось, что репозиторий с автотестами не всем разработчикам доступен (добавить всем разрешения не вариант - особенность проекта).
Сейчас приходится код переносить руками в другой репозиторий, который доступен всем разработчикам, а разарботку смок-тестов вести в репозитории на сервере заказчика. Костыльно.
Хочется более изящного решения и заодно для саморазвития полезно.

Нашел код таски, который генерит jar-файл со всеми зависимостями

Доработанный вариант:

task fatJar(type: Jar) {
    manifest {
        attributes 'Implementation-Title': 'SanityTests Jar File',
            'Implementation-Version': version,
            'Built-By': System.getProperty('user.name'),
            'Built-Date': new Date(),
            'Built-JDK': System.getProperty('java.version'),
            'Main-Class': mainClassName
    }
    baseName = project.name + '-all'
    from {configurations.compile.collect { it.isDirectory() ? it : zipTree(it) }} {
        exclude "META-INF/*.SF"
        exclude "META-INF/*.DSA"
        exclude "META-INF/*.RSA"
    }
    with jar
}

Предварительно, нужно переопределить источник исходников, т.к. по умолчанию в jar-е используются только исходники по пути - src/main/java:

sourceSets.main.java.srcDirs 'src/test/java'
sourceSets.main.java.srcDirs 'src/test/resources'

Класс с именем “mainClassName” содержит метод main:

public static void main(String[] args) {		
	org.testng.TestNG.main(arguments);
}

запуск
java -jarapptest-all-0.1.0.jar SmokeTest_SanityTest.xml

единый jar файл со всеми зависимостями создается и даже запускается TestNG - и тут же с ошибкой вылетает.
Проблема в том, что в jar подтягиваются только файлы *.class

поэтому содержимое папки src/test/resources - нет в jar-файле (в этой папке файлы настроек, драйвера)
И я не уверен, что имеет смысл ее туда помещать, лучше рядом разместить.

Как через таску градл скопировать папку resources и так, чтобы исполняемый код в jar мог ее найти?