Недавно я работал над проектом, в котором нам нужно было интегрировать отличный инструмент нагрузочного тестирования 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. |