Page Object Model for Performance Testing With Gatling
Gatling is a powerful open-source tool for performance/load testing; we take you through the POM design model to create and test a Gradle repository.
Join the DZone community and get the full member experience.Join For Free
It is one of the Non-Function testing techniques that test if and how SUT [System/Software Under Test] will perform under a load in terms of responsiveness, stability, scalability, reliability, and resource usage.
Many factors, like network, code quality, traffic spike, etc., could potentially hamper a system's performance. Perf testing helps to uncover these bottlenecks.
UI and API Performance Testing
There are 2 ways to load test the application. They are UI and API load tests.
UI load testing involves testing everything visible to users or the client-side. They evaluate the translation of data from the API to the UI and ensure that everything is happening quickly and accurately. These tests provide the best insight into the actual loading times experienced by users.
In API load tests, as the name suggests, we put the load on the application by hitting APIs directly and then checking how APIs are responding under various load conditions.
Gatling: Performance Testing Tool
There are many performance testing tools available. I have used Gatling for this article.
It's is a quite famous and powerful open-source tool for performance/load testing and provides integration with CICD tools like Jenkins.
It offers great reporting and an easy to use recorder and script generator.
It provides default integration with build tools like Maven and Gradle.
Page Object Model for Performance Testing
We have used the POM [Page Object Model] with UI automation tools; however, the same pattern we can very well use in Gatling.
Consider an example of https://katalon-demo-cura.herokuapp.com/. Here we have a journey, i.e.,
- Landing on the home page,
- Logging in,
- Booking an appointment,
- Navigating to the History page to confirm if the appointment has been successfully made.
- Logging out.
In the above example, I have shown just 1 journey, which traverses through multiple pages. On every page, there was a call to some API. We might need to use the same API differently to perform various other journeys, like with a different set of request parameters.
If we are using these same APIs in different journeys, then it leads to a lot of duplicate code.
An easy but effective way is the usage of POM in the above use case.
With POM, we will be extracting out the APIs page vise, and then these APIs can be called in various journeys or tests.
In this article, I have used IntelliJ as an editor and Gradle as a build tool.
Documentation for Gatling's Gradle plugin can be found here: https://gatling.io/docs/current/extensions/gradle_plugin/
Let's start with writing the code.
Step 1: Download Gatling: https://gatling.io/open-source/
Step 2: Set up the Scala plugin in IntelliJ: http://allaboutscala.com/tutorials/chapter-1-getting-familiar-intellij-ide/scala-environment-setup-install-scala-plugin-intellij/
Step 3: Create a new Gradle repository in IntelliJ as follows:
Input GroupId and ArtifactId as shown below and then Finish:
NOTE: We need to have Gradle already setup in our machines to get this set-up ready smoothly. I have used sdkman to get Gradle 6.3 on my machine.
Step 4: After the successful creation of the Gradle repository, open the build.gradle file and insert the below code in it:
Step 5: From the terminal window, run Gradle clean build to download all dependencies.
It will take some time to download the dependencies. After a successful Gradle build, our repository will look something like this:
With Gatling's Gradle plugin, we get the folder structure displayed above, with some sample files available.
- All the request payloads, CSV files for feeders, etc., can be kept inside the resources folder.
- All test simulations, any helpers, and Constant data files can be kept inside the scala folder.
Step 6: Let's start creating page object classes.
- Create 3 packages inside the Scala directory as
com.helperpackage create a scala class as
Constants.scalawherein we will keep all our common URLs, username and common password, and common header information:
BASE_URLis the main URL of our application.
- In the
URLSobject, we have kept all the API ends points which start from
SECRETSI am keeping usernames and passwords so that they need to be in code. As an enhancement, we can take these secrets from a vault.
- Our application under test has many headers. These various headers are stored in these variables.
- Create 5 .scala files in
BasePagefor all the common code like header information.
BasePage.scalafor common header information.
- In LandingPage, we are landing onto the application's main page using BASE_URL and asserting that API should give a status code as 200.
- We have created 3 methods here in AuthenticatePage: to get the User's profile, to Login, and to Logout.
- Since login call is a post-call that accepts form parameters in its request payload, I have used Gatling's method
passwordwe are importing from
ConstantsDatawhere the secrets are.
- In all these 3 methods, respective URLs also we are getting from ConstantsData.
- We have created 1 method here in AppointmentPage: to book an appointment.
- Since this call again is a post-call that accepts form parameters in its request payload, I have used Gatling's method
Seq()we need to pass the fields and their values.
- We have declared a variable as
httpProtocolhere which declares the
warmUpurl and all the headers.
- Under different header methods, we are passing respective headers, which we are importing again from ConstantsData.
Step 7: Let's write a journey test using these pages inside
- Every test in the Gatling world is known as a Simulation, and it has to extend a Gatling's built-in class known as Simulation.
- Our test will look like this:
- There are 3 parts in the test
appointmentwhich contains API calling in a sequence.
- a variable as
bookAnAppointmentwhich executes a scenario. This scenario name can be any user-relevant value as it gets displayed in the report.
setUpthat does user injection followed by assertions.
- I have kept the number of users as 50 with a ramp-up time of 50 seconds, i.e., in every 1 second, Gatling will create 1 virtual user.
- Depending upon whether AUT is an Open Or Closed Model, we can consider the load injection behavior. Here since this application is an Open model, I have taken this load injection method:
rampUsers(10) during (5 seconds)
Step 8: Running the tests.
- We need to specify the path of the test from the 'simulations' folder.
Step 9: Checking Reports.
- After successful execution, we can check out the reports inside the build/reports/Gatling folder by checking out the index.html file.
- index.html file looks something like this:
In this report, we can check various parameters like:
- The total number of users for every API. Every OK in Gatling is a success, and every KO means there is some failure.
- How much time the APIs took to respond.
- The number of requests per second.
- The number of responses per second.
I hope all of you readers find this article useful!
Coming next: Post for running Gatling performance tests in Jenkins and Dockerised setup.
Opinions expressed by DZone contributors are their own.