Недавно я работал над проектом, в котором нам нужно было интегрировать отличный инструмент нагрузочного тестирования Gatling в сборку на основе Gradle . Доступны плагины Gradle, которые делают это легко, два из них — это и это , но для большинства нужд достаточно простого выполнения самого инструмента командной строки , поэтому в этом посте будут рассмотрены некоторые детали того, как можно подключить gatling. в сборку Gradle и в процессе понять некоторые хорошие концепции Gradle.
Исходные наборы и конфигурация
Чтобы выполнить Gatling Cli, мне нужно что-то сделать, мне нужно место для исходного кода и связанного с ним содержимого моделирования Gatling, и мне нужен способ получить библиотеки Gatling. Здесь вступают в игру две концепции Gradle (SourceSets и Configuration).
Начнем с первого — SourceSets.
SourceSets
Исходные наборы представляют собой просто логическую группу связанных файлов и лучше всего демонстрируются на примере. Если бы я добавил плагин «java» в сборку Gradle:
|
1
|
apply plugin: 'java' |
Свойство sourceSets теперь будет отображаться с двумя значениями «main» и «test», и если я захочу найти подробную информацию об этих sourceSets, можно использовать задачу gradle для печати деталей:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
|
task sourceSetDetails { doLast { sourceSets { main { println java.properties println resources.properties } test { println java.properties println resources.properties } } }} |
Возвращаясь к гатлингу, я могу по существу создать новый sourceSet для хранения имитаций гатлинга:
|
1
2
3
|
sourceSets { simulations} |
Теперь можно было бы ожидать, что симуляции гатлинга будут находиться в «src / simulations / java», а ресурсы, связанные с ним, в папках «src / simulations / resources», что нормально, но в идеале я бы хотел, чтобы они были полностью отделены от проекта. источники. Я хотел бы, чтобы структура моей папки была с симуляциями нагрузки в «simulation / load» и ресурсами в папке «simulations / resources». Это можно настроить, сначала применив плагин «scala», который вносит в проект поддержку компиляции scala, а затем изменив источник «simulations», установленный по следующим направлениям:
|
01
02
03
04
05
06
07
08
09
10
11
12
|
apply plugin: 'scala'sourceSets { simulations { scala { srcDirs = ['simulations/load'] } resources { srcDirs = ['simulations/resources'] } }} |
С помощью этого набора изменений я теперь могу поместить свои симуляции в нужное место, но зависимость gatling и scala не была введена, вот где появляется функция «конфигурации» gradle.
конфигурация
Настройка Gradle — это способ группировки связанных зависимостей. Если бы я должен был напечатать существующий набор конфигураций, используя задачу:
|
1
2
3
4
5
|
task showConfigurations { doLast { configurations.all { conf -> println(conf) } }} |
они появляются:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
|
configuration ':archives'configuration ':compile'configuration ':compileClasspath'configuration ':compileOnly'configuration ':default'configuration ':runtime'configuration ':simulationsCompile'configuration ':simulationsCompileClasspath'configuration ':simulationsCompileOnly'configuration ':simulationsRuntime'configuration ':testCompile'configuration ':testCompileClasspath'configuration ':testCompileOnly'configuration ':testRuntime'configuration ':zinc' |
«Compile» и «testCompile» должны быть знакомы, то есть, где нормальная исходная зависимость и тестовая зависимость обычно объявляются так:
|
1
2
3
4
|
dependencies { compile 'org.slf4j:slf4j-api:1.7.21' testCompile 'junit:junit:4.12' } |
Тем не менее, похоже, что теперь доступна конфигурация для набора исходных текстов «simulations» — «simulationsCompile», «simulationsRuntime» и т. Д., Поэтому я могу объявить зависимости, необходимые для моих имитаций моделирования с использованием этих конфигураций, однако я намерен объявить настраиваемая конфигурация, чтобы немного углубиться в концепцию, поэтому давайте объявим ее явно:
|
1
2
3
|
configurations { gatling} |
и используйте эту конфигурацию для объявления зависимостей gatling:
|
1
2
3
4
|
dependencies { gatling 'org.scala-lang:scala-library:2.11.8' gatling 'io.gatling.highcharts:gatling-charts-highcharts:2.2.5'} |
Почти здесь, теперь, как мы скажем источникам в имитационном источнике, установленном для использования зависимости от конфигурации gatling … немного подправив sourceSet:
|
01
02
03
04
05
06
07
08
09
10
11
12
|
sourceSets { simulations { scala { srcDirs = ['simulations/load'] } resources { srcDirs = ['simulations/resources'] } compileClasspath += configurations.gatling }} |
Запуск сценария Гатлинга
С заданными исходными наборами и конфигурацией все, что нам нужно сделать, — это написать задачу для запуска симуляции Гатлинга, которая может выглядеть следующим образом:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
|
task gatlingRun(type: JavaExec) { description = 'Run gatling tests' new File("${buildDir}/reports/gatling").mkdirs() classpath = sourceSets.simulations.runtimeClasspath + configurations.gatling main = "io.gatling.app.Gatling" args = ['-s', 'simulations.SimpleSimulation', '-sf', 'simulations/resources', '-df', 'simulations/resources', '-rf', "${buildDir}/reports/gatling" ]} |
Посмотрите, как скомпилированные источники моделирования и зависимости от конфигурации gatling устанавливаются как путь к классу для задачи «JavaExec»
Хороший способ проверить это — посмотреть на полный рабочий образец, который я имею здесь в
мой репозиторий github — https://github.com/bijukunjummen/cf-show-env
| Ссылка: | Интеграция Gatling в сборку Gradle — Понимание SourceSets и Конфигурации от нашего партнера JCG Биджу Кунджуммена в блоге all and sundry. |