Forum Discussion
You need the testrunner.bat / sh to start soapUI from commandline. see link for the parameters.
For soapUI loadtests you need the loadtestrunner.bat/sh
For soapUI security (version >= 4.0) you need the securitytestrunner.bat /sh
etc.
An example of an ant build script to run soapUI (the ant script is used in Hudson, and is placed in the same dir (svn) as the soapUI project.)
<project name="soapUI_tests" default="soapui-tests-cmdline" basedir=".">
<!-- define project location -->
<property name="project" value="./ING_Checklist_BT2011.xml" />
<!-- define targets -->
<target name="SOAPUI_TestSuite">
<exec executable="${env.SOAPUI.BIN}/testrunner.sh" failonerror="false" failifexecutionfails="false">
<arg line="-sTestSuite -rja -f./reports ${project}"/>
</exec>
</target>
</project>
In Hudson you add an "Invoke Ant" testStep.
Target : SOAPUI_TestSuite
Buildfile : ./Build.xml
Properties : env.SOAPUI.BIN=/opt/soapUI_latest/bin (this is the ${env.SOAPUI.BIN that is used in the Ant build script)(soapUI_latest is a symbolic link)
Since my commandline invocation returns a (full!) report (JUnit) of the testrun, Hudson can collect the report and show it as testresults with the "after build" action: "Publish JUnit test result report".
In the field "Test reports XMLs" enter : reports/TEST-*.xml (or the relative path to your report location) and build.
Hello
where i should store build.xml file? in the same directory with soapui xml project file?
and how to integrate with git, to allow jenkins to pull latest project from repository before execute them?
- nmrao7 years agoChampion Level 3
It is up to you where to store, but that should help you and your team and easy to use.
If you are using git, then maintain it in a way such that it is to track changes to sopui project in conjunction with your Application version.
For example, you got an application whose version is 1.0 and you created SoapUI project to the API of the above.
In git, maintain a directory structure say : automation/1.0/, then have SoapUI project related artifacts under it.
Also have build.xml there.
So any one in your team pulls them they get the same structure, so the Jenkins as well.When you application (under test) version gets upgraded to say 1.2, you create the respective directory structure for automation as there are chances that new operations / methods gets added / modified / deleted and soapui project needs to undergo the same. So, create new directory structure in git say : automation/1.2.
- This way, you have the artifacts available any time, even if you need to provide some hot-fixes on Application1.0, you can use artifacts under automation/1.0.
Hope this helps.