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.