Functional Web Services Testing Made Easy with SoapUI - Part 3

3. Integration with CI
Continuous integration is all about compiling, testing, inspecting, and deploying to your application server at each commit. The benefit of CI is simple: when you build software often, you will find code defects early. A lot of CI servers are available, both open source and commercial. Hudson is an open source CI server with a very simple set up, just three steps (yes you heard me right, just three steps):
a. Download the latest version of Hudson.
b. Open a command window and type java -jar hudson.war
c. Open up a browser and go to the url http://localhost:8080
That’s all you need to get the CI server up and running in less than two minutes. You can read more about configuring Hudson and downloading all the plugins and much more at the link here.

As we will now see, it’s very easy to run the functional tests we wrote in this series once we deploy our application to a server. If all the tests run, the build file will generate JUnit reports; these reports can be integrated within our CI dashboard. If any of the tests fail, we fail the build, using the failonerror attribute of the Ant task. Based on how CI has been set up, everyone in the team can receive an email or a text message should the build break.

Let’s take a look at how we run these functional tests and integrate them with CI:
Once you have Hudson installed and running, you must add your projects to Hudson as Jobs for it to monitor these projects. We are going to create a single job which runs at midnight.

1. Go to the Hudson main page, and click New Job. This will open a page as such:

2.Enter a descriptive name since this is the name which will be displayed on the Hudson dashboard. Select the "Build a free-style software project". Click the OK button and you’ll be presented with yet another screen

3. In this screen, select your source code management. You will be presented with a detailed screen based on your SCM. Fill in all the details. Hudson needs all this information to checkout all the source code assets to build the project.

4. Hudson can be configured to build your project on a scheduled basis, or periodically. In our case the job needs to run at midnight. So, here are the changes needed to run the job on a nightly basis.

5. Next step is to configure Hudson to properly build our project using Ant. As you can see from the image above, Hudson provides many ways for building your project. In the PetStore case, I am setting up some environment variables and therefore using a simple batch file.

6. In the Post-Build Actions section, we will select the Publish JUnit test result report option. We are generating the JUnit reports from SoapUI. Specify a location for where Hudson can find the XML files that JUnit produces when run through Ant.

7. Now, that we have Hudson setup. we will force the build. This will cause Hudson to checkout all the source code artifacts from SCM, and initiate a build. In my case the build failed; reason being SoapUI generates the JUnit reports with no package name, Hudson complains about the same and throws a NPE. A possible workaround to publishing the JUnit reports, is to use the Achive the artifacts option in Post-build Actions. Here are the Hudson screenshots and the output:

Hudson console output: