Why not make SoapUI step names more than descriptive?

I was continuing my journey with SoapUI. One of the challenges was to develop a test infrastructure with a low maintenance overhead. I am doing contracting work once it is over, in-house staff should be able to maintain it.

I was using Groovy script only when it is absolutely necessary, and setting up the custom content type was such task. Content type was read from a property, but I thought setting the property manually for every content type is not going to be reliable. It is easy to lose or change it without ever noticing it.

SoapUI suggest to use descriptive names for test steps. This is a very practical and useful suggestion. But can we go one step further? This is a technique I started using even in manual testing environments. You can include various data about the entity in different fields. The name can contain some useful data. If it is a database table, use values from a numeric column when testing a text column, so that you can verify them easily.

So, in this case I thought of including the content type in the name itself, and reading it from step name. There was an additional advantage of not having to modify the script in anyway when copying it to a new test. Just change the name. The following script read the name and use the string preceded by "-" to set the content type.

Re-usable Groovy scripts for SoapUI

For couple of days I could not login to blog - but with kind of frequency I was blogging in last year, it should not make any difference.

Though I stared to use SoapUI with some reluctance (mainly due to the fact that the project I am working is a REST system and I thought SoapUI's support for REST cannot be that great) I made good progress and became more and more comfortable with it.

One test I had in mind was verifying response headers. Using the Groovy script was the most straight forward method to do that. However, in all the examples I found, Groovy script was referring to the step by name to access the response data. This meant editing the script every time I used it in a different place. SoapUI pro has a scripting library but I was using the free version.

Then I thought the best way is to write the script to get data from the previous step, regardless where it is. In this way, I don't need to change the script every time I use, but just to place it write below the step where I need to test the headers. This was the script I came up with.

SoapUI: Verifying a url in the content of a page

We had a little discussion on SoapUI test cases and one question was could we extract an url from the response and use load the content from the page it is pointing to. This was important as we were testing a RESTful framework. Task is trivial when using a programming/scripting language (I was planning to develop the test framework using Perl and it would have been just couple of lines) but could not think of a reliable way of doing it in soapUI. The biggest problem was when a test step is defined as a REST request, you can't arbitrarily change the endpoint (You can, but found sometimes it does not actually use the updated link).

The trick is to have a test step as a HTTP request instead of REST. Then the endpoint is kind of free form. In a property transfer step, XQuery nicely extracted the url and set as the endpoint of HTTP request. Bingo! it's done!

This is how I did it. Say you have the following XML content in a response and wanted to create a request for the url in tag <myweb>

<Everybody>
<me>
  <myweb>http://www.myweb.local</myweb>
  <...>... </...>
  <...>... </...>
</me>
<...>
<...>
</Everybody>

I used a property transfer with following settings. Note that you have to declare the namespaces if exist in the response.

Press run, there you have the endpoint of 'goto myweb' request is set!

It has been a while ..

Did not have a chance to look at this for a while. After starting to work at Auckland transistion authority as a test manager in last July, life got kind of busy, till I finished the contract in December 2010.

Started working at AUT on their new student portal. It is an interesting job. Inintially the plan is to use Perl to automate it, but changed to SoapUI. I kind of started liking soapUI more than I expected. User freindliness is limited in the free version :-) but I'm impressed with the flexibility. I could implement all the tests planned under Perl infrastructure using soapUI and it is quite an achievement. I will post some of the techiques used in this blog.