Load Testing Using Gatling and Java #2

 

In the previous article, we walked through the steps to create and execute a basic Gatling simulation, laying the foundation for performance testing using this powerful tool. Building on that knowledge, this article takes things a step further by focusing on how to construct a scalable and organized framework around Gatling. We’ll explore essential components that bring structure, reusability, and flexibility to your performance testing efforts. From organizing simulations and managing configurations to integrating utilities and reports, this discussion will help you turn a simple simulation into a robust testing framework. You can find the complete source code for this project here.

Client

client package defines client classes, in our case it is CarsClient.java. We have defined all the operations related to cars in this class

BaseSimulation.java

We have created a base class which extends to Simulation class. Every other simulation class extends to this BaseSimulation.java instead of extending directly to Simulation class.

This base class provides common setup and configuration that can be reused by other simulation classes that extend it. 

Key Components of BaseSimulation:

Logger:  

A logger instance is created using SLF4J and Logback for logging information. This logger is used to log important details during the simulation setup and execution.

Config:  

The Config object is loaded from a JSON file using the ConfigProvider class. This configuration contains environment-specific settings that are necessary for the simulation. The configuration is loaded using the ConfigProvider.getConfig() method. This method reads the configuration from a JSON file based on the current environment.

HttpProtocolBuilder:

An HttpProtocolBuilder instance is configured with common HTTP settings that will be used for all HTTP requests in the simulation. This includes the base URL, headers, and other settings.

logback.xml

The logback.xml file is a configuration file for the Logback logging framework. It defines how logging is handled in the application, including the format, level, and destination of log messages.

Appenders: 

CONSOLE: Logs messages to the console with a specific pattern and without immediate flush.

FILE: Logs messages to a file named simulation.log with a specific pattern and without appending to the existing file.

Loggers: 

io.gatling.http.engine.response: A specific logger for the io.gatling.http.engine.response package set to TRACE level, which logs detailed information about HTTP responses.

Root Logger:

The root logger is set to INFO level and uses both the CONSOLE and FILE appenders to log messages.

src/main

Inside main we have defined constants, URLs, standard headers, custom headers, constants, helper methods and modes.

The helpers package contains three classes ConfigProvider,  Properties, TestDataProvider. 

ConfigProvider class is responsible for loading and providing configuration data for the application. It uses the Gson library to parse JSON configuration files and provides methods to access the configuration data. It ensures that the configuration is loaded only once and provides synchronized access to the configuration data. 

Properties class is responsible for managing and retrieving system properties, particularly the environment property. It ensures that the properties are valid and handles mandatory properties.

The TestDataProvider class in the helpers package is responsible for generating random test data using the Faker library. It provides various methods to generate random names, nicknames, mobile numbers, alphanumeric strings, email addresses, street addresses, full addresses, UUIDs, and random numbers.

The models package contains classes that represent the data models used in the application. These classes are typically used to structure and manage data, often corresponding to JSON objects or database entities. 

env.json

The env.json file is a JSON configuration file that contains environment-specific settings for the application. Each environment configuration includes an environment name (env) and a corresponding configuration object (config) with specific settings such as the baseUri.

Running the Simulations

To run the cars simulations, use the following script.

 ./gradlew gatlingRun --simulation qajournal.simulations.Cars -DenvName=perf-a -DtestDuration=30 -Dmultiplier=2

Cars setup profile:

The above script defines three system properties.

1. envName : This property specifies the environment used to execute the simulation. In our example, the environment is set to perf-a. The configuration object is initialized using the provided system property, and the baseUri is adjusted accordingly.
2. testDuration : This property defines the run duration of the simulation in seconds.  testDuration system property, is converted to an integer in BaseSimulation, and is assigned to loadDuration variable. This variable is then used to configure the duration of the load test in the setUp method of the Cars class.
3. multiplier: In the BaseSimulation class, the multiplier system property is parsed as an integer and assigned to the multiplier variable. This variable configures the constantUsersPerSecond parameter in the setup method of the Cars class. For example, if the multiplier is set to 2, the simulation runs with a load of two constant users per second. This approach enables runtime control of scripts without modifying them directly, allowing dynamic adjustments based on the multiplier value.

gatling.conf

The gatling.conf file is the central configuration file used by Gatling to manage and customize various aspects of its runtime behavior. This file allows you to fine-tune important settings such as simulation timeouts, request throttling, resource limits, and output report directories. Adjusting values in this configuration file can help optimize test execution performance, manage memory usage, and define logging levels. Whether you want to change the default number of simultaneous connections or set a different location for reports, gatling.conf gives you control over how Gatling operates during your performance tests.

build.gradle

In build.gradle file, the gatlingImplementation and implementation configurations are used to specify dependencies for different purposes: 

gatlingImplementation: This configuration is specific to the Gatling plugin and is used to include dependencies that are only needed for Gatling simulations. These dependencies are not included in the main application runtime class path.

implementation: This configuration is used to include dependencies that are needed for the main application runtime.

I hope this article helps you get started with running load tests using Gatling. Load testing is an essential part of building scalable, high-performing applications, and mastering tools like Gatling can make a big difference. In the next article, we'll explore Gatling's built-in reports and how to interpret them effectively to gain meaningful performance insights. Until then, Happy Testing! 🚀