As with SOAP services, once a REST service has been added to a project soapUI can automatically generate a test suite for the service. Right-click on the service's node in the workspace tree and select "Generate TestSuite" from the context menu. The Generate Test Suite dialog looks very similar to the corresponding dialog for SOAP services, allowing you to choose the resources for which you'd like to generate tests, whether you'd like all of the generated tests grouped into a single test case or assigned to their own test cases, etc.:
Let's leave the default options and click OK. A test suite is generated with one test case for each of the REST service resources we defined previously. By default, test requests use the parameter values that were set when the corresponding service request was added to the project. However, these values can be changed in a test request's parameters table, and you can use them with property expansion. Open the cardId test case and create a test case property called testCard and give it the value "chain-reaction". Open the editor for its lone test request (Retrieve Individual Card Info) and use soapUI's property expansion syntax to specify the testCard property of the test case as the value of the test request's cardId parameter-- enter "${#TestCase#testCard}". Click the Send button (the green arrow) for the test request. Looking at the response, we can see that the data returned does indeed correspond to the card named Chain Reaction:
Remember that you can specify different parameter types in the parameter table, so you can use property expansion with any of them: URI parameters, resource path parameters, request body parameters, etc.
Let's move on to creating an assertion. Up until now in my posts I've focused on web services that return response data as XML; this REST service gives us an opportunity to look at how soapUI handles JSON data. SoapUI's solution for dealing with JSON data is really pretty straightforward-- it generates an XML representation of the same data set. Consequently, all of the same XML-based content assertion types are available to use with JSON response data. Note the tabs running along the left side of the panel showing the response data, and (if necessary) click on the one labelled "XML" to view the response in XML format.
Click on the Assertions button at the bottom of the Request Editor to open the Assertions panel, click the Add Assertion button, and add a new XQuery Match assertion. The service returns data for multiple editions of the same card, so we'll use our assertion to confirm some expected values for the two editions of the Chain Reaction card. Click the Declare button at the top of the assertion's configuration dialog to add a namespace declaration and add an XQuery expression to return data for the card's editions; the expression with its declaration should look something like this:
Click the "Select from current" button to capture the expected result of the expression, then save the assertion with the test request. When dealing with XML-based assertions and JSON response data, note that even though the XML is auto-generated by soapUI, a namespace declaration and namespace prefixes are still needed. Also be careful of extra tags in the XML (such as the "e" tags around each set of edition data) that do not exist in the original JSON but are inserted by soapUI to delineate some JSON data structures in the conversion.
could you please write about jsonpath and more about groovy on soapUI?
ReplyDeletemany thanks
I just put up a new post covering JsonPath expressions: http://testautomationnoob.blogspot.com/2016/01/soapui-building-jsonpath-expressions.html. I'm hoping to write up another post soon covering handling some JSON in Groovy Script steps.
Delete