Update Gatling to 3.x

[oemergenc]

Hi,

are there any plans on updating to gatling 3.x ?

[chriskilding]

Hi Oemer, I moved off the team where we were doing significant load testing so had to leave development of the library for a while. However I'm now in a place where load testing is relevant once more, so I am in a position to resume development.

I can certainly see about upgrading Gatling to 3.x, which will happen within the wider roadmap described below...

[chriskilding]

In phase 1 of development we built the fundamental capabilities:

• Work out how to express load tests as plain old xUnit tests.
• Work out how to execute those test definitions with the drivers.
• Work out how to express SLOs in code.

This was enough to get load testing off the ground for my team/company, and others like yourselves who work in similar ways to us. However the limited uptake of the library so far suggests that not enough of the story around load testing has been worked out yet. There are missing parts of the story that we need to write, before load testing as a whole becomes as easy as unit testing.

I would see the roadmap of phase 2 looking something like this...

• Maintenance and dependency upgrades. (What you're asking for)
• Work out whether a Maven plugin is needed. (Today we include the driver jar directly on the classpath, which can cause dependency issues. A Loadtest4j Maven plugin would turn Loadtest4j 'inside out'. Similar to Surefire/Failsafe, it would discover load tests, inject the drivers + config, and run + report on the load tests.)
• Work out the story for running those tests in a continuous delivery pipeline. (Today we run load tests like normal xUnit tests - as a one-shot synchronous step in the CD pipeline. But is there a more natural way to run load tests?)
• Work out where the SLOs should be tested. (Today we test them on the client side, but servers also log their own response time metrics to their own sinks like CloudWatch. Those metrics are potentially valuable as they include real-world usage. Should we consider them?)
• Work out how to make our IDEs more aware of load tests. (Representing results graphically, running the load tests selectively etc.)

I am receptive to any suggestions you may have on those points - our team alone certainly doesn't have all the answers.

[oemergenc]

Hi Chris, thank you for your fast answer. Your roadmap looks very interesting. Locking forward to what is coming up. I just want to mention it and maybe you already saw it, there is another library which is implemented in a similar way like loadtest4j. Have a look here:

https://github.com/vgalloy/gatling-java-api

It provides a DSL which stays very close the the original scala bases syntax of gatling. Unfortunately the artifact was never released and i tried to contact the author but he never responded.
Maybe there are chances that your team and you can take any profit from is.
I build the artifact locally and it works with Gatling 3.0.