1

I am checking Rest Assured now, and want to understand its performance. So, I created 2 unit tests:

public static final String C_URL = "http://ergast.com/api/f1/2017/circuits.json";

@Test
public void test_getCircuitsFor2017Season_only() {

    System.out.println("test_getCircuitsFor2017Season_only");

    long time = System.currentTimeMillis();
    given().
    when().
    get(C_URL);
    System.out.println(System.currentTimeMillis() - time);

}


@Test
public void test_apache4() {

    System.out.println("test_apache4");

    CloseableHttpClient httpclient = HttpClients.createDefault();
    HttpGet httpGet = new HttpGet(C_URL);
    try {
        long time = System.currentTimeMillis();
        CloseableHttpResponse response1 = httpclient.execute(httpGet);
        System.out.println(System.currentTimeMillis() - time);

    } catch (IOException e) {
        e.printStackTrace();
    }

}

And the results are:

test_apache4
223
test_getCircuitsFor2017Season_only
1027

Is it a fair test? Can performance be improved for Rest Assured?

Thanks!

New contributor
dushkin is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
  • Does are not unit tests as your testing a remote site. – dzieciou Jun 12 at 14:30
0

Is it a fair test?

Not really.

  • Performance tests usually involve warm-up phase as anonygoose suggested in his/her answer. For instance, in case of HTTP clients this is to let them start thread and HTTP connection pools.
  • Performance tests should sent many requests over time. If you're sending only one request you might be simply out of lack as the server or network can be busy at this particular moment.
  • REST-assured is a wrapper around Apache HTTP Client so you could expect that only overhead is to translate your requests to calls to HTTP client and response back. However, REST-assured might be using a different version of Apache HTTP client than you did. Also, Apache HTTP client has tens of configuration parameters to tune its performance. It could be the reason that the configuration you have used is different than the default configuration used by REST-assured. Finally, by default REST-assured creates a new Apache HTTP Client instance for each REST-assured call.

Can performance be improved for Rest Assured?

Probably yes. You can:

There's also one question you haven't asked:

Why is it important to have fast tests with REST-assured?

  • 1
    "Why is it important to have fast tests with REST-assured?" :) From my side I was checking Rest Assured vs. an in-house rest framework performance. After all, I wouldn't want to use a very slow tool if I have a faster one. – dushkin Jun 13 at 4:53
1

According to this question Rest Assured is pretty slow on the first request you make. Looks like it has to warm up a little for some reason.

I've tested version 4.0 of Rest Assured myself, and this appears to be the case. The first request is 2000ms+, then every subsequent request in the same suite is 200-300ms.

A counter question might be: why compare them? Rest Assured is for testing API requests and is extremely rich in terms of features and ability. The HttpClient from apache is for making requests and comes with none of the testing features.

If you are making requests in order to test them, use Rest Assured. If you're making requests as a means to an end, use HttpClient.

  • So you suggest that to use Rest Assured I should accept performance degradation as a side affect? – dushkin Jun 12 at 12:59
  • 2
    I think it's a reasonable trade-off for the testing capabilities that Rest Assured provides. With further experimentation it appears to be slower on the first request per test run, not suite. So if you're running 10s/100s of suites at the same time, the large delay is only seen once. While even 2 seconds per test run may not be ideal to you, you'll spend far more time making your own API testing framework around HttpClient if you don't use a pre-built one. It may be worth asking the creators of Rest Assured about the delay. There's always the chance that it could be improved. – anonygoose Jun 12 at 14:39
  • Thanks anonygoose! – dushkin Jun 13 at 5:07

Your Answer

dushkin is a new contributor. Be nice, and check out our Code of Conduct.

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.