Test performance to avoid failures

A few months ago, I had a chance to do a performance testing workshop based on the REST API. For a couple of years, I have been using gatling.io, and the following case study is presented with this tool.

While I was preparing for the presentation, I often stopped for a moment with the thought of what could have gone wrong and turn ROOVEE project into a nightmare. I also remember that from the very beginning of development, our team stayed focused on testing performance. We wanted to avoid the possibility of negligence, or even if we were going to fail, we would fail early.

Always test early, even performance

Understanding the performance of your code in the early stage of development will decrease costs (for refinements, refactors, etc.). Therefore, testing performance is essential. And for that particular project, testing how the application will behave under a load of users was crucial even more. Another burning question is when to test performance? As soon as possible and I don’t say it to sassy you. It’s genuine - test performance once you have developed the first functionality.

Testing perspective

Here’s a short case study pointing out some of the most critical activities, such as testing performance.

Let’s assume that the alpha version of our application has the following functionalities:

1. Bike rental
2. Bike reservation
3. Rental history

Those functionalities can determine the scope for performance testing. But first, let’s analyze our “money path” - the scenario of bike rental.

To rent a bike user needs to do the following steps:

1. Run the application
2. Select bike’s icon
3. Tap Rent

In the second scenario, the user needs to:

1. Run the application
2. Select bike’s icon
3. Tab the reservation button

As you can see, one of the actions is repeated in each scenario - opening the application.

From the performance perspective action “Run application” is one of the most loaded by the system. Once the contract for the endpoint has been set and the requirements refined, I started developing a performance test.

Here’s a request that is made under the hood

GET https://api.ourbikesharing.com/bikes/available?longitude=16.95812642&latitude=52.40045212&latitudeDelta=0.08386940&longitudeDelta=0.26321053

Sample scenario with gatling.io

package bikesharing
 
import io.gatling.core.Predef._
import io.gatling.http.Predef._
import scala.concurrent.duration._
 
class GetBikesAvailableInSection extends Simulation {
  val httpConf = http.baseURL("api.ourbikesharing.com")
 
  val scn = scenario("Get available bikes")
      .exec(http("Get")
      .get("/bikes/available?longitude=16.95812642&latitude=52.40045212&latitudeDelta=0.08386940&longitudeDelta=0.26321053")
      .check(status.is(200)))
 
  setUp(scn.inject(atOnceUsers(3000))).protocols(httpConf)
}

This sample scenario simulates stressing the endpoint with 3000 virtual users at once. The purpose of the test is to check whether every request is finished with a success status.

We can use this scenario to test performance either manually or automatically. No matter if our pipeline contained tests or not, every team member could run them smoothly. What matters more is doing them, and as you can see, it won’t require a substantial investment of effort.

If you want to know more about Gatling configuration, on how to start testing with the tool and more, go to my GitHub repository.