SoapUI: Output TestCase Results to Excel

As you can tell from the rest of my posts, this is again using SoapUI Pro and making use of the DataSink test step and the Extended Script Library.

So, in my test case results, I’d like to see the test case number, description, status, assertion, and the date it was run. In my Excel docs I have each of those as a heading and then SoapUI just starts at the next row. Since I take my initial test cases also from Excel I get the test case Id and description from that Datasource.

The DataSink step I set to be Excel (from the dropdown) and then I get the option to add properties on the left. As mentioned, I create five properties:
1) TestCaseId
2) TestCaseDescription
3) Status
4) Assertions
5) Date

TestCaseId and TestCaseDescription are easy since they are already in my Datasource:

${Datasource#TCId}
${Datasource#TCDesc}

Status can just be called using a Groovy script inline, like so:

${=testRunner.results[testRunner.results.size()-1].status}

The ‘1’ in the above example is the location of the test request in relation to the DataSink.

Assertions references a script in my Script Library, which could look like:

${=new qa.GetFailedAssertions().outputResult(testRunner)}

And then the actual script looks like:

package qa

public class GetFailedAssertions {

	def outputResult(testRunner) {	
		def tcName = testRunner.testCase.name
		def assertionList = testRunner.getTestCase().getTestStepByName(tcName).getAssertionList()
		
		for( assertion in assertionList ) 	{
			for(e in assertion.errors ) {
			return "Assertion Failure: [" + e.message + "]"
			}
		}
	}
}

Date is just today’s date with the time, again inline Groovy script:

${=new java.text.SimpleDateFormat("yyyy-MM-dd'T'HH:mm").format(new Date())}

Now when I run my case all these results are put into the files referenced in the File parameters of the DataSink.

SoapUI: Composite projects and SVN

If you have multiple testers that need to use the same project you can make use of the composite project option in SoapUI Pro and some type of SVN.

So, first you want to have some kind of SVN repository setup where you are going to sync your project to. Once you have this created you can create your folder structure under it that you want to use with SoapUI. For example, if you use Groovy scripts for automation you can also include those in a folder and commit them to the SVN so everyone can also have access to update them.  For this example we’ll say your folder structure looks like this under a root folder called ‘SVN’:

folderstructure

Now you want to open SoapUI.

Save your project under the Projects directory we just created. Select it at the root level in SoapUI. You’ll see project properties at the bottom:

soapuiProjProps

You want to make sure Composite project is set to true. Now instead of your projects being a single xml file they’re broken up so they look something like this:

testSuites

Each test suite is broken up into its own folder. There are also element.order and settings.xml files. If you look at these files (in notepad or some variety of) then you can see that element.order is just the order of whatever items are in the level you’re looking at. At the root it’s the order of the test suites, inside a test suite it’s the order of the cases. Settings.xml is the various environment and project properties at the root level and the test suite ones at that level.

Remember the Scripts folder?  Well you can set your global SoapUI properties to be the folder that you plan on putting on SVN.

ScriptsSettings

Now that everything is setup you can go to the root level (C:\SVN) and do your SVN Checkout. Then you’ll want to do the SVN Commit.

Everyone else using the project can now setup their own SVN folder and checkout your work. Note that in order to see new test suites/cases in SoapUI after an SVN update you need to do a Refresh Composite Project:

refeshproj

This will update your SoapUI to what is now in your local copy from SVN (which by doing the SVN update should now match what’s on the SVN).

Good rule of thumb, as if you were developing, would be to update at least once a day if not twice and Commit anything that is completed or you don’t want lost.  Typical scenario would be:

Tester A creates new test suite
Tester A saves SoapUI project (this is now saved to his/her local copy ONLY)
Tester A commits said project to SVN (if it’s a new test case in an already existing folder you can always just commit the folder)
Tester B does an SVN Update
Tester B goes to SoapUI project and does a Refresh Composite Project
Tester B sees Tester A’s test suite

SoapUI Groovy: Disabling a test step within a test case

If you want to disable a specific test step that’s in all your test cases, at the Setup Script level for your TestSuite, here’s what you can do:

def totalTestCases = testSuite.getTestCaseCount();

for(n in (0..totalTestCases-1))	{    
 	if (testSuite.getTestCaseAt(n).getTestStepByName("MyTestStep")){
 			testSuite.getTestCaseAt(n).getTestStepByName("MyTestStep").setDisabled(true)
	 	}
}

Enjoy!