soapUI Tips n Tricks – Part 2

This post is a follow up on my earlier post – soapUI Tips n Tricks – Part 1. I hope my readers find this post as much of use as the previous one. In this part, I shall try to cover simple but little more involved soapUI tricks. Once again please note that tips n tricks covered in this post may or may not apply to you as soapUI keeps evolving with its newer releases. Nevertheless, its useful to have a list of nuances and workarounds to those handy as you may find those useful for a given version of soapUI.

1. Composite Projects in soapUI: soapUI by default, stores the project in one xml file. You can open this project file in soapUI by importing it. You can even edit this xml file in any simple editor, if you know what exactly you want to edit “in bulk” at times. soapUI, however, introduced concept of “composite project” in version 2.5. You can turn ON composite project by selecting “true” option in front of “Composite Project” property under your project’s properties listed on left hand bottom pane when you open your project. The default value for this property is set to “false”. Once you set this property to “true”, soapUI starts saving this project under a directory – as a composition of multiple directories – one each for each binding, each TestSuite. Each test-case is then stored under each TestSuite directory as an independent xml file. This is useful when you have multiple people working on different test-cases in a single project. So one person does not run over changes made by the other assuming the two are working on two different TestSuites OR two different test-cases. On caveat with using composite projects is when you use this feature with version control systems. When you change names of your test-cases the version control system is not aware of this name changes, hence you land up having multiple version of same file when you do next “update” in your version control system like cvs or svn. Then you shall have more headaches maintaining multiple versions of files and deleting old ones and do this as an extra step as opposed to soapUI + version control take care of it for you.

2. Using soapUI code-templates on Mac: soapUI introduced another new feature in version 2.5 Pro and that was code-templates. If you open up soapUI preferences, you shall find a tab “Code Templates”. In here you shall find that you can define a block of code for a given string. For example, you can provide a string “savefile” and perhaps have 10 lines of code that represents this repetitive task of saving to a file. Later in your groovy script you can enter word “savefile” and press CTRL+SPACE and that auto completes this word into the block of code you defined in your code templates preferences. In fact this is documented on soapUI website. What they don’t tell you is this does not work as expected on Macs. On Macs you have to use SHIFT+SPACE instead of CTRL+SPACE to achieve the same!

3. Using dates in dynamic property expansion: soapUI 2.5 has very useful feature – dynamic property expansion. Again this is reasonably documented on soapUI website. I found this incredibly useful when dealing with web services that are time sensitive and your test cases always need to have dates that are say “5 days from now”. As your test-case grows older it starts failing as it refers to the hard coded dates. This is where you can make use of dynamic properties right within your SOAP Request step or even provide it in properties for TestSuite, Project or TestCase and then substitute this property in your SOAP Request step. Here is an example:

   ...
   ...
    <!-- text within dateEffectiveFrom tag is replaced with a date 10 days from today in yyyy-MM-dd format -->
    <dateEffectiveFrom>${=  String.format('%tF', new Date() + 10) }</dateEffectiveFrom>
   
   <!-- TestSuite property "date" is defined as "${=  String.format('%tF', new Date() + 10) }" -->
   <!-- Another example where dynamic date is defined as TestSuite property -->
   <!-- and then SOAP Request can refer to this TestSuite property as shown below -->
    <dateEffectiveFrom>${#TestSuite#date}</dateEffectiveFrom>
   ...
   ...
   

4. Running TestSuite cases in parallel: For a long time I kept using the default soapUI behavior that runs all test-cases in a given test suite in succession one after the other. I realized that soapUI provides an option to run these test-cases in parallel as well. This is very useful if you have a number of test-cases in your testsuite and you want to save time by running them in parallel as opposed to waiting for one test-case to complete to execute another, of course, assuming that the sequence execution of test-cases does not matter. Image below shows the default (third from left) option selected where tests run in serial fashion. If you select the (fourth option from left) option that shows arrows in parallel, this makes your tests run in parallel when you hit green “play” button to execute the test suite.
   

5. Disabling TestSuite, TestCase or a test step: I find this feature very handy especially when I am working with a number of test-cases at a time and want to put one test-case on hold and come back to it later. If you right click on TestSuite, TestCase or Test Step in soapUI, you shall notice an option in pull down menu called “Disable TestSuite” or “Disable TestCase” or “Disable Test Step” as the case may be. If you select this option the corresponding test suite, test case or test step shows up in grey color. So next time you run the project, test suite or a test case the corresponding disabled test suite, test case or a test step is not executed as a part of that run.

6. Datasource Options: Do take advantage of Datasource options provided when using ‘Datasource’ step in soapUI. Let’s refer to the datasource options available in soapUI Pro:
   
   Pay attention to “Start Row and End Row” options shown above. These are very handy when you want to test your code for just a few rows initially. If you don’t set these to any value, datasource shall process all the records in your data source. Using “trim data values” is also a handy option when dealing with string values. I find “go to loop” very handy as well as this takes care of any empty rows especially say when you have a given excel file with hundreds of records and many rows are empty at random. This way you don’t have to worry about empty rows in your groovy code.

7. Be careful using testRunner.gotoStepByName in your groovy script: This may not be obvious to you the first time you use this method on testRunner. Logically, if you use this code in the middle of the script you would think that the execution of this script would stop and move to the next step defined in the call. But that is not what happens in reality. When you execute this call in a groovy script step, the entire groovy script step has to finish first and then only the flow of control moves to the step given in the call ‘gotoStepByName’. This is because this call is invoked on testRunner and for testRunner ‘test step’ being executed is the smallest unit of work and that needs to complete before test runner executes next direction given by the call ‘gotoStepByName’. Hope this clears your confusion if you had any regarding this call on testRunner.

8. My SOAP Request steps uses dynamic property expansion but I want to capture actual xml with data: If your SOAP Request step uses dynamic property expansion by substituing actual data in xml using TestSuite properties or test case properties your request would have heavy use of expressions like ${#TestSuite#property1}. When you execute this test-case or testsuite, soapUI retains these expressions. In other words when you double click on fresh SOAP Request step just executed (that shows in green assuming it succeeded) you shall see the expressions and not the actual data. In many cases you might want to capture the actual xml data being sent. What you do is follow the soapUI log from soapUI log tab at the bottom. The log shows steps being executed one after the other. Once you see the step you are interested in the log, double click on it and that opens up this SOAP Request step in SOAP Message viewer where you can see request and response xmls in a message viewer. You can simply format this xml and copy paste in order to capture your data within xml.

9. Make sure you check off “Use XQuery” when using X Query in property transfers: In one of my earlier posts on Property Transfers using XPath and XQuery, I had explained how to use XQuery expression in property transfers in soapUI. Figure below shows the XQuery I used in my example in that post. Do remember to check off “Use XQuery” option as shown in the figure. This is a common mistake made and you would probably not even realize the mistake even though “Use XQuery” option is in right front of you.
   

10. Using paths relative to project directory: soapUI project has a property ‘Resource Root’. Be default its blank. But you can select ${projectDir} as its value from the drop down given. You shall find this property in project’s properties under left hand side bottom pane. If you select ${projectDir} as your resource root all paths are resolved with respect to your project directory or project file.

I hope you found this post of some use. I guess I shall stop here until I come back with part 3.

~srs