Understanding Gatling Scripts: A Use Case
After we learned how to record a Gatling script, this blog post will dive into the details of that script and explain it. The purpose is to understand the different parts so you will be able to write your own load testing script in Gatling without having to record it. We will cover four parts of the script: setup, HTTP configuration, scenario and simulation.
Let’s get started. We will explain the script we recorded in the previous blog:
If you don’t know Scala, this script might be intimidating. But don’t worry. Let’s look into how the script is structured, A closer look shows us the script is divided into four sections:
- Setup - preconfiguration and class declaration
- HTTP Configuration - configuring HTTP and variables
- Scenario - the story executed
- Simulation - the test configurations
This step configures the package name to hold the scala class, indicates the required imported libraries and shows the class declaration.
In this script, the package has the name “blazemeter”. This is an optional requirement.
Then, import common libraries:
These libraries are stored in the Lib directory of Gatling. Each library contains commands that we use in the script. If you don’t import libraries, the script will fail to compile because the compiler does not know where to define commands.
For example, assume we don’t import the library “scala.concurrent.duration._” that contains the (.pause()) method. So, when compiling, the script will fail because it does not recognize the (.pause()) method.
The next line we define is a class named “BlazemeterPricing” with the extended Gatling class Simulation “class BlazemeterPricing extends Simulation”.
This step we will define the HTTP configurations and variables for the script, like: the protocol, URL, headers. These will be used as the headers of the API endpoint. We will clarify them line by line.
- 1 - The main URL that will prepend all URLs.
- 2 - Parses HTML to find embedded resources and load them asynchronously.
- 3,4,5,6 - Common headers that will be sent with all requests. For more details on http header fields please click here.
- 7,8,9 - Defines headers to pass to the individual request. We will see how they can be used in the scenario section.
- 10,11,12 - Some constant variables. These variables are auto created by recording. They are not necessary in this script so we can remove them.
The option you will often change is baseURL(//1), the others are kept as default for most cases.
In this section we will define the actual scenario that will be executed. Let’s take a look at it line by line.
- 1 - Defines a variable named scn. It is assigned to the syntax scenario that has name BlazemeterPricing.
- 2 - Calls .exec() method. It comes with the syntax http and has the name request_0. This name will appear in the report.
- 3 - Executes the .get() method and calls the endpoint with the URL http://www.demoblaze.com.
- 4,8,11,15- Sends defined headers to individual requests that are mentioned in the http configuration section above.
- 5- Fetches resources in parallel to emulate the behavior of a real web browser.
- 6,9- New requests named request_1, request_2
- 7,10- Starts a new .get() method and calls endpoints with the URL http://www.demoblaze.com/css/fonts/Lato-Regular.woff2 and http://www.demoblaze.com/imgs/front.jpg
- 12 - Pauses 8 secs
- 13 - A new call with the .exec() method with the name request_3
- 14 - A new .get() method that calls the endpoint with the URL http://www.demoblaze.com/cart.html
The scenario describes two actions of user behavior. First, the user browses to the page http://www.demoblaze.com. Second, the users clicks on the “Cart” text link http://www.demoblaze.com/cart.html after waiting 8 secs. The browser will send 2 GET method API endpoints to the server along with the headers declaration in the HTTP configuration section.
According to your scenario, you can edit/change the code to suit the behavior you want to test.
In the final section of the Gatling script, we introduce a scenario profile that will be executed in the load test. The configuration for the scenario profile indicates parameters for the load test like which protocol to use, how many concurrent users to run, the ramp-up period, etc.
- setUp: Gatling syntax for this part
- scn: The variable that we created in the scenario section
- inject(atOneUsers(1)): Configures the users for the load test. In this example, it configures one user for load test
- protocols: Gatling syntax
- httpProtocol: The variable that we defined in the HTTP configuration section
You can customize parameters to meet your load test purpose. For more simulation configuration information please click here.
I hope this blog is helpful for you to write your own Gatling script for load testing!
Running Your Gatling Script in BlazeMeter
After creating your Gatling script, you can achieve massive scalability by running your Scala file in BlazeMeter and ramping up to 1,000s or 1,000,000s of users from scores of geo-locations worldwide. You will also get more advanced reporting that you can drill down into and compare over time, sharing and collaboration on tests and reports, and the ability to shift left.
To try out BlazeMeter, put your URL in the box below, and your test will start in minutes. Or, request a live demo from one of our expert performance engineers.