Robot Framework - RequestsLibrary vs. REST-assured bakeoff

Hey, folks - I’m trying to win an internal bake-off to show that RF is more than capable of holding its own against Java-based frameworks.

If you take a look at the example at the REST-Assured website, you’ll see a hypothetical example they show. Their Java code looks like this:

@Test public void
lotto_resource_returns_200_with_expected_id_and_winners() {
    when().
        get("/lotto/{id}, 5).
    then().
        statusCode(200).
        body("lotto.lottoId", equalTo(5),
        "lotto.winners.winnerId", hasItems(23, 54));
}

I’ve managed to replicate the functionality with one exception - the last assert where it’s expecting to see 2 values - 23 & 54. Not sure how to do that in RF except have something like:

Lotto Resource Returns 200 With Expected Id And Winners
    # code that does the first part - not shown for brevity...
    # The variable ${lotto_return} is the ${resp.json()} from the GET
    Dictionary Should Contain Value    ${lotto_rtn}[lotto][winners][winnerId]    23
    Dictionary Should Contain Value    ${lotto_rrn}[lotto][winners][winnderId]    24

I’d like to collapse those last two lines into one, but am not sure how. I realize this is more of a generic question (or maybe aimed specifically at the Collections library). However, I figured folks on this sub-channel would have dealt with something like this before.

TL;DR Help me win the bakeoff against a Java framework using REST-Assured!

2 Likes

You could use List Should Contain Sub List (robotframework.org). You’d have to construct the list with expected results first though, but being explicit in naming your variables / expectations is a good thing, in my book. The Java example has a lot of magic numbers in it, which is bad for maintenance.

If you really need a one-liner, it’d be something like

Evaluate    assert [23, 54] in ${lotto_rtn}[lotto][winners][winnerId]

Note that I would not approach such a comparison on “which framework can do it with the least amount of lines of code”. That’s a terrible way to evaluate something in a context where readabilty and clarity of intent is much, much more important.

Also note that the Java example does 3 tests / assertions within a single test case and the name of the test has one of the expected values hard-coded in its name. I consider that very bad practice.

How I would build the test is more something along these lines:

Test succesful request on /lotto/{id}
    ${lotto_id}=    Set Variable    5
    ${expected_response_code}=    Set Variable    200
    ${expected_winner_ids}=    Create List    23    54

    ${response}=    GET    /lotto/${lotto_id}
    Should Be Equal    ${response.reponse_code}    ${expected_response_code}
    List Should Contain Sub List    ${lotto_return}[lotto][winners][winnerId]    ${expected_winner_ids}
1 Like