Представляю Вашему вниманию перевод статьи с Medium "Smith — Serverless Test Runner"
Попробуйте вспомнить, как часто вы попадали в такую ситуацию? За день до дедлайна Вы запускаете массивный набор интеграционных тестов и оставляете их "вариться" на ночь. А утром с ужасом в глазах Вы узнаёте, что половина из них попадала из-за случайного сетевого сбоя?
А сколько раз вас просили вечером "по-быстренькому" запустить наборчик смоук-тестов, чтобы проверить последний билд. И вот уже за полночь, а Вы всё сидите и ждёте результатов...
Ну и конечно, когда Вы поднимаете вопрос о том, что надо бы докинуть серверов для агентов, вы раз за разом получаете один и тот же ответ - "Прости, дружок - на этот квартал/год/век бюджет уже распланирован"...
Но подождите. А что если Вы скажете им, что можно запускать сколько угодно тестов, распараллелив их на сколько угодно серверов, при этом не держать ни железо, ни запущенные виртуалки на постоянной основе?
Давайте прикинем. Допустим раз в сутки Вы пускаете ночные тесты, которые выполняются 4 часа. Вы их параллелите на 2 постоянно запущенных сервера-агента, дабы уложиться в это время. Таким образом 20 часов в день две машины будут просто "курить в сторонке", грея атмосферу и пожирая Ваши кровные деньги. Было бы здорово, если эти бравые ребята получали сдельно, а Вы оплачивали бы только за проделанную работу. Использовать сервера на 100% и потом просто "погасить" их. И делать это быстро. И делать это не написав ни одной строчки кода... Чтож, теперь это возможно!
Представляем Вашему вниманию новый фреймворк распределённого выполнения тестов - Smith. Суровый агент возьмёт Ваши тесты, разделит их, поднимет виртуальные сервера, выполнит тесты, сохранит результаты и погасит использованные машины.
Говоря о Serverless первое, что приходит на ум это - AWS. И да, Smith сделан исключительно на AWS.
Smith предоставляет простое REST-api как входную точку. API Gateway дёргает Lambda-функции, которы разделяют ваши тесты, складывают их в очереди и запускают ECS-джобы. Именно ECS и делают "грязную работу", выполняя тестирование (ну или что угодно). По завершению теста логи аккуратно складываются в S3, а результаты улетают в SQS, откуда их можно "потребить". ECS-виртуалки, естественно, при этом "гасятся". Эдакий, Мистер Мисикс получается.
Из архитектуры видно, что вы платите только за выполненную работу, а не за простаивающие в сторонке сервера, 89% времени просто ожидающие "наряда на вино-водочный". Smith гарантирует, что КПД системы выполнения будет близко к 100%.
Smith - это всего лишь Cloud Formation шаблон, который можно скачать бесплатно. Он создаёт все необходимые ресурсы. Все ресурсы, создаваемые шаблоном, являются Serverless и не требуют ни копейки денег при простое: S3 бакеты, SQS очереди, Лямбды, API Gateway и ECS сервис.
Чтобы запустить тесты в единственную, созданную шаблоном, API-ручку надо POST-ом отправить запрос со списком тестов. Например:
{"launchId": "ID_OF_TEST_LAUNCH", "executables": [
{ "testcaseUuid": "1", "metadata": { "projectId":"com.testquack", "artifactId":"smith-maven-s3-tests", "version":"1.0-SNAPSHOT", "package":"com.testquack.smith.maven", "class":"TestScopeTest", "method":"resourceDataTest"}},
{"testcaseUuid": "2", "metadata": { "projectId":"com.testquack", "artifactId":"smith-maven-s3-tests", "version":"1.0-SNAPSHOT", "package":"com.testquack.smith.maven", "class":"TestScopeTest", "method":"simpleTest"}},
{"testcaseUuid": "3", "metadata": { "projectId":"com.testquack", "artifactId":"smith-maven-s3-tests", "version":"1.0-SNAPSHOT", "package":"com.testquack.smith.maven", "class":"TestScopeTest", "method":"simpleTest"}},
]
}
Как следствие под каждый такой тестовый класс или метод (параметр "method" в объекте необязательный) будет поднята и выполнена ECS-джоба. Логи будут сохранены в S3-бакете “smith-reports-[REGION]-[ACCOUNT_ID]”, а результаты - что прошло, что - нет - будут отправлены в “smith-results” SQS.
Подключаемся
На данный момент Smith поддерживает Maven JUnit тесты. Но ведётся активная работа по внедрению поддержки Gradle, NUnit, Pytest, т.д.
Чтобы Smith мог выполнить Ваши тесты, он должен иметь к ним доступ.
Для начала надо запаковать Ваши тесты в test-jar. Для этого в прокект можно добавить вот такой плагин
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>3.2.0</version>
<executions>
<execution>
<goals>
<goal>test-jar</goal>
</goals>
</execution>
</executions>
</plugin>Далее нужно поделиться этими тестами со Smith-ом. В случае, если вы деплоите прямо в Maven Central - то дальше можно не читать - всё произойдёт само. Но, скорее всего, это - не Ваш случай.
Чтобы предоставить тесты Smith-у вы можете указать свои кастомные репозитории в settings.xml файле и просто загрузить его в корень бакета “smith-private-settings-[REGION]-[ACCOUNT_ID]”, созданного шаблоном. В этом случае ваш settings.xml будет использован внутри ECS контейнера и указывать Maven-у путь истинный.
Другой путь - задеплоить ваши тесты прямо в S3, созданный шаблоном Smith. Для этого в build секции указываем wagon-plugin
<build>
<extensions>
<extension>
<groupId>com.testquack.smith</groupId>
<artifactId>s3-storage-wagon</artifactId>
<version>1.0</version>
</extension>
</extensions>
...
</build>Далее - в свой ~/.m2/settings.xml добавляем репозиторий с авторизацией в Вашем AWS-е:
<server>
<id>my-repo-bucket-snapshot</id>
<username>AWS_ACCESS_KEY</username>
<password>AWS_SECRET_KEY</password>
<configuration>
<region>us-east-1</region>
</configuration>
</server>
<server>
<id>my-repo-bucket-release</id>
<username>AWS_ACCESS_KEY</username>
<password>AWS_SECRET_KEY</password>
<configuration>
<region>us-east-1</region>
</configuration>
</server>Ну и, наконец, указываем distribution management в pom-файле проекта, который укажет на ваш бакет
<distributionManagement>
<snapshotRepository>
<id>my-repo-bucket-snapshot</id>
<url>s3://smith-artifacts-snapshot-[REGION]-[ACCOUNT_ID]</url>
</snapshotRepository>
<repository>
<id>my-repo-bucket-release</id>
<url>s3://smith-artifacts-release-[REGION]-[ACCOUNT_ID]</url>
</repository>
</distributionManagement>Вот и всё, “mvn clean deploy” запакует Ваши тесты и загрузит артефактом в ваш бакет, созданный шаблоном Smith. Остаётся только вызвать API и выполнение начнётся.
Выполнение
Как уже было сказано ранее - Smith создаёт API Gateway эндпоинт, POST-запрос на который запускает тесты. Но, как говорится, есть способ лучше.
Т.к. Smith является детищем компании GreatBit, то он тесно интегрирован с её продуктами. В частности - с системой управления тесткейсами - QuAck. В базовой поставке QuAck уже входит Smith Launcher - плагин, позволяющий запускать тесты в Serverless облаке Smith из удобненького интерфейса. Более того, QuAck получит, сохранит и отобразит результаты выполнения.
Для того, чтобы запустить тесты из QuAck - их туда нужно импортировать. С этим прекрасно справляется вот этот плагин. Просто добавляем его в проект - и каждый раз при пересборке тесты в QuAck будут обновляться по необходимости.
Импортировали тесты, перешли в QuAck, выбрали себе сьют тестов и запустили, выбрав Smith как Launcher. Всё, можно идти пить кофе - результаты в системе себя не заставят долго ждать.
Эпилог
Цель Smith - не только ускорить выполнение тяжёлых тестов за счёт разбиения выполнения на отдельных машинах, но и сократить расходы на инфраструктуру. Нет же никакого смысла платить за сервера, которые ничего не делают, а только ждут своего часа пробежать короткий спринт. Вы платите только за выполненную работу, а не оплачиваете счета за электричества в чужих дата-центрах.
А самое приятное - это всё бесплатно. И Smith, и QuAck. Бери, настраивай, запускай, экономь и радуйся. Ну а если возникают вопросы - разработчики из команды GreatBit всегда спешат на помощь.
