Introduction to Load Testing with Gatling – Part 4

By | May 6, 2016
Gatling logo, used with permission.

Gatling logo, used with permission.

This is the fourth, and last, part in a series of posts in which I will present a written version of a workshop I recently held on load testing with Gatling. The target audience of the workshop was Java developers without any previous knowledge of Gatling and this series of articles is not different in this area.
Since I myself like concrete examples, the workshop was based a number of examples. A project containing all the examples is available on GitHub.
Earlier articles in the series are: Part 1part 2 and part 3.

Example 6 – Checks and Assertions

In this, the sixth, example I will show how to perform checks on responses and assertions on statistics of the entire simulation or part of it.

Note that:

  • The scenario “Scenario1” sends a HTTP GET request to /unknown relative to the base URL.
    There is no such URL and thus the request should return the 404 HTTP status code.
  • After the GET request there is a call to a method named check on row 29.
    As the parameter(s) to this method we supply one or more checks that we wish to perform on the response.
    In this example we want to assert that the HTTP status is 404.
  • Chained onto the invocation of the setUp method, there is a call to a method assertions on row 43.
    As parameters to this method we can make assertions on statistics from either all requests (global), each individual request (forAll), a group of requests (details) or a single named request (details).
  • On row 43 there is an assertion that the maximum response time of all requests in the simulation must not exceed 500 milliseconds.
  • On row 44 there is an assertion that for each request, the number of failures must be less than five.
  • On row 45 there is an assertion that for the request with the name “Bad Request”, the number of successful requests must be greater than 90%.

Run the simulation with the following terminal command:

The result should be a successful simulation.

Tweak the parameters in the assertions and re-run the simulation or try to add additional checks or assertions and see what happens.

Example 7 – Multiple Checks and Verification of Request Payload

The seventh example shows how to make multiple checks on a response and, as one of check-types, make a check against the payload of the response.

Note that:

  • The status check on row 28 checks against a range of status codes.
    In the example the expected status codes are just three; 200, 201 and 202.
  • There is an additional parameter to the check method.
    As before, checks are added as parameters to the check method.
  • The additional parameter to the check method starts with a call to a method named regex.
    The regex method searches the response body for the supplied regular expression, in this case just the string “Computer database”.
    The methods chained onto regex first returns the number of occurrences of the search expression and then asserts that the number is greater than or equal to one.

Run the simulation with the following terminal command:

The result should be a successful simulation.

Change the parameter to the greaterThanOrEqual method to 5 and re-run the simulation.
There will be an error in the simulation that renders the following output to the terminal:

From the error message we can see that there were one single occurrence of the string, not five as the simulation expected.

Example 8 – Simulation Inheritance

Recall the first part of this series, in which I mentioned that Gatling simulations are Scala classes. With a background in object-oriented programming, I naturally start to think about whether it is possible to create some kind of template for a certain type of load-tests and then, through the use of inheritance, define load-tests for specific cases without having to duplicate the common parts.
My goal was to be able to only set values of instance variables in my subclasses. In order to accomplish this, I created this base-class for my load-test simulations:

Note that:

  • The HttpSimulationBaseClass is an abstract class that extends the Gatling class Simulation.
  • There are four instance variables defined in this class.
    scenario1BaseURL – This will be the parameter to the HttpProtocolBuilder method baseURL and the base URL of all requests in simulations inheriting from this class. Default value is the empty string.
    scenario1RequestPath – Additional URL path that will be appended to the base URL for the request in scenario one of simulations inheriting from this class. Default value is the empty string.
    finalUserCount – The maximum number of simulated users that the simulation will ramp up to. Default value is 10.
    userCountRampUpTime – A duration specifying the time during which the simulated users will ramp up.
  • There is a before-block of code containing a call to the method doSetUp.
    Also in the first part of this series I mentioned the before block as a place to put arbitrary Scala code that is to be executed before the simulation begins. Since I want to specify parameters to the load-simulation template using instance variables, I cannot rely on assigning the scenario builder and HTTP protocol builder to instance variables, because then they will be initialised as part of the base-class instance creation, before the subclass have had a chance to insert values into the instance variables.
  • There is a method named createHttpProtocolBuilder.
    As the name implies, this method creates a HTTP protocol builder. The contents of the methods should be familiar, but earlier the resulting HTTP protocol builder was assigned to an immutable instance variable directly. The instance variable scenario1BaseURL is used to set the base URL of the HTTP protocol builder. Note that in Scala, the return keyword can be omitted, as in this method.
  • There is a method named createScenarioBuilder.
    Not surprisingly this method creates a Gatling simulation scenario builder. In this method, the instance variable scenario1RequestPath is used as parameter to the get method.
  • Finally the doSetUp method appears, which is the method called from the before block earlier.
    This method calls the two methods seen earlier to create a HTTP protocol builder and a scenario builder and then invokes the setUp method we have used in our load-simulations earlier. In this method, the instance variables finalUserCount and userCountRampUpTime are used as parameters when specifying the number of users and the ramp-up time for users.

Nice, but we cannot run this as it is. Lets look at an example showing how to use such an abstract base-class for load-simulations:

Note that:

  • The class HttpSimulation8 extends the abstract base-class we just created.
  • This class only contains four assignments to the instance variables from the base-class.

Run the simulation with the following terminal command:

The result should be a successful simulation with four requests being sent.

This concludes this series in which I introduced load-testing with Gatling.

Happy coding!

2 thoughts on “Introduction to Load Testing with Gatling – Part 4

  1. Freeman

    Very interesting buddy.

    A question, how i can inherit a Objet from another Scala file(another class)?

    In this Class i have a web service request


    1. Ivan Krizsan Post author

      I don’t think I entirely understand your question, but I guess that you want to access an instance field/property or method in an instance of another Scala class.
      Since Gatling simulations are Scala code, you could create an instance of the other class in the Gatling simulation and invoke the method, or access the property, on the instance from the Gatling simulation.
      Hope this helps!


Leave a Reply

Your email address will not be published. Required fields are marked *