Performance testing is an essential part of the Software Delivery Lifecycle (SDLC). However, it is often overlooked or done too late in the cycle to really make a difference; how can one expect an app’s performance to get better if tests are happening after release, right?
Introduction
Liatrio is big on shifting the test process to the “left” in the SDLC. It allows engineers to take ownership over the quality of their products as well as enabling a fail-fast approach to software development. Most importantly, shifting left integrates testing into software development itself — which affords just-in-time learning for engineers to find mistakes as they happen and reduces waste cycles that would otherwise come at the end.
Performance Testing as Code
Traditionally, performance testing is run “manually” — meaning that an engineer actually clicks on a button to launch the test suite. That’s not ideal, especially in a DevOps setting. The solution for that is to automate performance testing early in the process.
That’s where tools like Gatling, k6, locust, etc. come in handy. With these code-based solutions, code can easily be reviewed, versioned, compiled, and run. Essentially, when using a code-based tool, the test suite is treated as software — which makes it much easier to integrate to a pipeline.
Why Gatling?
First and foremost, Gatling is a great “as Code” performance testing tool. It is developed in Scala (JVM based language) and so it is compatible with Java, making it easily extensible. Being a code-based tool, developers tend to prefer it over other GUI-centric tools like JMeter.
With that in mind, we’d like to introduce our “run-gatling” GitHub Action. This Action makes it easier for developers/SDET to integrate their Gatling test suite into a CI/CT GitHub workflow.
How to use the Action?
As with any other GitHub Action, you simply have to reference the Action within your workflow like so:
# execute tests- uses: liatrio/run-gatling@v1.2.0 with: pomPath: my_test_suite/path# execute a specific simulation- uses: liatrio/run-gatling@v1.2.0 with: pomPath: my_test_suite/path simulationClass: simulationsPkg.MySimulationClass
As per the two different scenarios above, there are three ways to execute your Gatling test suite:
- Executing a whole test suite
- Executing a specific Simulation*
*A simulation in Gatling is what defines the type of test you are running: the throughput, the virtual users, the duration, the thresholds, etc. For more information on Gatling’s core concepts, please refer to the official docs (Also, be on the lookout for our upcoming blog on how to structure your Gatling test suite!)
Viewing results
We’ve included a test report that’s posted on your job’s summary page. It allows you to quickly check if your app’s performances are in line with expectations. At the moment of writing this blog, the summary looks like this*:
*It’s important to note that this feature is in continuous improvement.
Conclusion
Performance Engineering is a game changer whether you’re a startup or a large enterprise. It makes the customer experience that much more enjoyable, but it also drives cost savings on infrastructure (Cloud and On-Premise).
Hopefully this got you excited to pick up Gatling (if you haven’t already), integrate our Action to your pipelines, and deploy blazing fast applications to production 😁 !
