10 June 2009 - 3.0-beta-2 |
![]() |
|
As a complement to the sample soapUI Project, we also have a small sample REST Project. This can be used as an illustration to how REST requests and response looks in soapUI.
In the project is a small MockService simulating three responses: One simulated Yahoo News Search with an XML response One simulated Yahoo News Search with a JSON response One simulated v Yahoo News Search on the Web
Note: REST mocking is not supported in soapUI 2.5, so we?ve used the static file Mocking Option in soapUI. This is a generally very useful option; you could possibly have a number of files saved in a directory and serve them randomly for testing purposes. If you want to use Static File Mocking, it?s very easy;
Open the MockService. There are no MockResponses in the MockService, click the settings button
In the setting you can see one of the settings being called ?Docroot?, which has the value ${projectDir}/restexample/. ${projectDir}/ is a Environment variable you can always use in soapUI. It is particularly useful because it makes it possible to move projects easily between different computers. If you are using files containing settings or data for data driven tests, you can just put these in a sub subdirectory to the project and reference to them by using ${projectDir}/ instead of an absolute path like c:\eviware\projects\myProject. So we?ve placed the files the MockService serves in a directory called restexample which is placed in a directory under the project directory.
Ok, let's start the MockService; press the Start Button, and we?ll look at the tests.
The first TestSuite we?re going to look at is called ?1) Sample RestRequests TestSuite?. It contains just three small requests that deliver different types of responses.
Let?s look at the REST Request with XML Response. We choose what kind of response we?d like by setting the Type variable in the request and setting the Variable to Template. What Request we want to use is done by setting the Resource path, in this case we?re doing a search for Madonna, so we?ll set it to Madonna_xml.xml, we simplify this by using property expansion and we take the property type and expand it like this: madonna_{type}.{type}. From the WADL we get the full path NewsSearchService\V1\ madonna_xml.xml.
Now, fire of a request! The response will be an XML formatted response.
Now let's look at a JSON response, open up the JSON Request TestCase. As you can see it?s the exact same request with just one thing different, the type now is JSON. This is a major benefit in using properties and property expansions.
If we look at the response a JSON response differs quite drastically, although both well structured and data centric.
If the XML looks like this:
Madonna appeals for girls school help Madonna has taken a break from her world tour to ask fans to help her build a girls school in Malawi. http://uk.news.yahoo.com/1/20081114/ten-madonna-appeals-for-girls-school-hel-c60bd6d.html http://uk.news.yahoo.com/1/20081114/ten-madonna-appeals-for-girls-school-hel-c60bd6d.html world entertainment news via Yahoo! UK & Ireland News http://uk.news.yahoo.com/ en 1226647203 1226647267
The JSON looks like this
"Result": [ { "Title": "Madonna appeals for girls school help", "Summary": "Madonna has taken a break from her world tour to ask fans to help her build a girls school in Malawi.", "Url": "http://uk.news.yahoo.com/1/20081114/ten-madonna-appeals-for-girls-school-hel-c60bd6d.html", "ClickUrl": "http://uk.news.yahoo.com/1/20081114/ten-madonna-appeals-for-girls-school-hel-c60bd6d.html", "NewsSource": "world entertainment news via Yahoo! UK and Ireland News", "NewsSourceUrl": "http://uk.news.yahoo.com/", "Language": "en", "PublishDate": "1226647203", "ModificationDate": "1226647267" },
Now let?s look at the final Request. This is different in the respect that it?s not a REST Test Request, but a HTTP Test Request. These two are quite similar though, but are different in the respect that and HTTP Test Request is not connected to a REST Resource. We have changed the HTTP TestStep to contain two parameters, just in order to show how parameters can be used.
The Response contains normal html.
Of course all the Assertion functionality of soapUI is available in REST testing as well,
making soapUI uniquely powerful for REST Testing.
Let?s look into a real use case in order to show the functionality.
A very common use of REST Services, especially JSON formatted services, is that the service is used by a web page taking the data and displaying it in some form. Therefore you need to test, not only that data is sent correctly from the Web Service, but also that it is being processed correctly on the Web Page. Let?s validate the REST Response.
Open the TestCase called Compare xml and html in the Sample Comparison TestSuite. As you see, you can in soapUI write a description for each TestCase. This in-system documentation makes it easier to cooperate on tests.
Open the TestStep REST Test Request. It contains two assertions, one XPath assertion checking that the first title is equal to a property we have saved in the TestCase.
The Properties can be accessed from the Properties tab in the TestCase.
The Second being a simple check that the response contains the word Madonna, which is what we searched for.
Now, let?s check that the Web Page rendering works. Open up the Madonna html TestStep and look at the assertions. We just have one assertion, but this one checks that a certain element in the HTML is the same one as the first Title in the response, making sure that the test does not break if the content changes. This was a weakness with earlier assertions; if you can try making your tests parameterized or make them content free.
This concludes the small example project for RESTful web services. Enjoy your Web Service testing!