2

Let's say I have a REST service that allows you to search for rail journeys - and that once you have selected them, you can book them. The endpoint is example.com/service/v1/book, and to create the booking, you use a POST.

Because in reality, when you get to the booking state, the request would require a lot of data, the details of the booking are send as JSON.

For simplicity's sake, let's assume the body just takes the journey legs at the moment:

{
    "journey" : {
        "type" : "return",
        "outgoing" : {
            "from" : "LON",
            "to" : "NCL"
        },
        "return" : {
            "from" : "NCL",
            "to" : "LON"
        }
    }
}

Now, for a one-way ticket, that bit would obviously look slightly different, yet the resource (or HTTP method) wouldn't change - it would still be POST example.com/service/v1/book:

 {
    "journey" : {
        "type" : "single",
        "outgoing" : {
            "from" : "LON",
            "to" : "NCL"
        }
    }
}

The service would have to deal with it slightly differently, though. So, we'd want to test both.

How would you structure that in SoapUI?

I thought you'd create the resource (with the POST method), then create two different test cases, "one-way" and "return".

What I'm not sure of is how I'd then be able to pass the different payloads in? And where they'd be defined...?

3
  • Are you using Pro or community, I will assume Pro unless and amend my answer if required.
    – ECiurleo
    Commented Jan 7, 2016 at 10:40
  • The community edition, unfortunately.
    – Christian
    Commented Jan 7, 2016 at 19:31
  • Updated accordingly. It does mean you will need a case for each route you want to test
    – ECiurleo
    Commented Jan 8, 2016 at 8:28

1 Answer 1

2

I have working in a not dissimilar industry and had the following setup;

TrainTestSuite (this might be per supplier/operator)

-testcase->SingleBooking

-testcase->ReturnBooking

Both would utilize the same endpoint as the Test Suite

Within each test case I would have the following;

  • Properties (containing from and to locations)
  • PropertyTransfer (Transfer values to JsonSingleRQ using xpath)
  • JsonSingleRQ (your JSON request)

Duplicate this for your return journeys (obviously with additional values in the properties). I would suggest to treat them as independent values rather than transferring to opposing targets on the return.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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