7

I'm creating a test case for a REST API in soapUI 4.5 where I'm going to use the content from step X to make a new call in step Y.

Ideally I'd create the REST request with some parameters, say A and B, and say that these parameters should be used in the URL: http://myapi.com/v1/stuff/A/B

Then I'd do a property transfer step and simply set values extracted from step X into A and B.

It looks as if soapUI only lets me create querystring parameters, like this: http://myapi.com/v1/stuff?ParamA=A&ParamB=B

This works of course, but I'd like to be able to call it both ways, to verify they're both working.

Am I missing something?

snaits
  • 330
  • 1
  • 3
  • 9

1 Answers1

11

I am not a soapui expert by any means, but have just worked through a very similar scenario, so this might help you out.

Part 1: Create a paramatized resource
In my service, I have a resource called stuff:

http://{host}/stuff

I create a child resource with the below values:

    Resource Name: Get stuff by ID
    Resource Path/Endpoint: {stuffId}

and before clicking ok, click Extract Params - this will populate the Parameters table with an entry like:

    Name     | Default value | Style      | Location
    stuffId  | stuffId       | TEMPLATE   | RESOURCE

then click ok. You now have a resource that allows you to dynamically supply an id:

http://{host}/stuff/{id}

you would need to repeat this to create the B parameter above (or you could create A and B as two parameters to the single resource if you never call /stuff/A without also supplying B).

Part 2: Create the test case
Now in the test case, you need to retrieve A, transfer the property, and then send a request to the above resource using the property:

  1. In the test case, create the request to retrieve the response containing A
  2. Right click the testcase and add a Properties step. Add a property to store the value of A.
  3. From the response in the Outline view, right click the value of A and select "Transfer to > Property", select the property you just created and hit ok

  4. Create a new request, using the new paramatized resource created in the first part. In the place of the id, put a reference to the property which is holding the value of A in this format: 

    ${propertyName}

I might have done something wrong, but my test initially fails on the property transfer with "Missing source property". In the Source are of the PropertyTransfer step, I needed to set the property to ResponseAsXml

Hope this helps!

Brendan
  • 213
  • 2
  • 6
  • Thanks, that works! I didn't get the LOCATION parameter though. And do you have any idea about optional parameters? They end up like {foo} in the url if don't give them a value. – snaits Oct 24 '12 at 13:35
  • Maybe the Location field is only in certain versions - it is used to show what level you are creating the property at (eg,Project, Service, Resource etc), so can be inferred based on the context that you are acting in (ie, we are creating a new resource, so want the property to be defined as part of this resource). In a RESTful world (well, probably in all worlds) there is no such thing as an optional uri parameter. There is one resource with the parameter and one without, and they are separate resources. – Brendan Oct 25 '12 at 12:44