After that, it is time to write our first stress test. It is important to notice that writing stress tests for Gatling is writing a Scala class using the provided DSL. Even for people who has never seen Scala is pretty intuitive how to use it.
So create a directory called src/test/scala and create a new class called AverageOrbitalPeriodSimulation.scala with next content:
Every simulation must extends
Simulation object. This simulation takes base URL of the service from
starwars_planets_url environment or system property, it creates the scenario pointing to the endpoint defined in
JAX-RS, and finally during 3 seconds it will gradually add users until 10 users are running at the same time. The test will pass only if all the requests succeed in less than 3 seconds.
Now we need to run this test. You will notice that this is not a JUnit test, so you cannot do a
Run As JUnit test. What you need to do is use a runnable class provided by
Gatling which requires you pass as argument the simulation class. This is really easy to do with
Gradle.
We are defining a
Gradle task of type
JavaExec, since what we want is to run a runnable class. Then we make the life a bit easier for developer by automatically detect that if
starwars_planets_url is not set, we are running this test into a machine that has Docker installed so probably this is the host to be used.
Finally we override the environment variable if it is required, we set the runnable class with required properties and we configure
Gradle to execute this task every time the
test task is executed (
./gradlew test).
If you run it, you might see some output messages from
Gatling, and after all a message like: please open the following file:
/Users/..../stress-test/build/reports/gatling-results/averageorbitalperiodsimulation-1459413095563/index.html and this is where you can get the report. Notice that a random number is appended at the end of the directory and this is important as we are going to see later. The report might looks like:
At this time we have
Gatling integrated with
Gradle, but there is a missing piece here, and it is adding the
continuous part on the equation. For adding continuous stress testing we are going to use
Jenkins and
Jenkins Pipeline as CI server so for each commit
stress tests are executed
among other tasks such as compile, run unit, integration tests, or code quality gate.
Historically
Jenkins jobs were configured using web UI, requiring users to manually create jobs, fill the details of the job and create the pipeline through web browser. Also this makes keeping configuration of the job separated from the actual code being built.
With the introduction of
Jenkins Pipeline plugin. This plugin is a Groovy DSL that let's implement you the entire build process in a file and store that alongside its code.
Jenkins 2.0 comes by default with this plugin, but if you are using Jenkins 1.X you can install it as any other plugin (
https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Plugin)
So now we can start coding our release plugin but for the purpose of this post only stress part is going to be covered. You need to create a file called
Jenkinsfile (the name is not mandatory but it is the de-facto name) on the root of your project, and in this case with next content:
In this case we are defining a new stage which is called Stress Test. Stage step is only used as informative and it will be used for logging purposes. Next a node is defined. A node is a
Jenkins executor where to execute the code. Inside this node, the source code is checked out from the same location where
Jenkinsfile is placed, sets a new environment variable pointing out to the location where the application is deployed, and finally a shell step which executes the
Gradle test task.
Last step in Jenkins is to create a new job of type Pipeline and set the location of the Jenkinsfile. So go to
Jenkins > New Item > Pipeline and give a name to the job.
Then you only need to go to
Pipeline section and configure the SCM repository where the project is stored.
And then if you have correctly configured the hooks from
Jenkins and your SCM server, this job is going to be executed for every commit, so your stress tests are going to run continuously.
Of course probably you have noticed that stress tests are executed but no reports are published in
Jenkins, so you have no way to see or compare results from different executions. For this reason you can use
publishHtml plugin to store the generated reports in
Jenkins. If you don't have the plugin installed yet, you need to install it as any other
Jenkins plugin.
PublishHtml plugin allows us to publish some html files generated by our build tool to
Jenkins so they are available to users and also categorised by build number. You need to configure the location of the directory of files to publish, and here we find the first problem, do you remember that
Gatling generates a directory with a random number? So we need to fix this first. You can follow different strategies, but the easiest one is simply rename the directory to a known static name after the tests.
Open
Gradle build file and add next content.
We are creating a new task executed at the end of
test task that renames the last created directory to
averageorbitalperiodsimulation.
Final step is add after
shell call in
Jenkinsfile next call:
publishHTML(target: [reportDir:'stress-test/build/reports/gatling-results/averageorbitalperiodsimulation', reportFiles: 'index.html', reportName: 'Gatling report', keepAll: true])
