SoapUI usage and integration within a CI environment Part I: an enumeration of best practices and lessons learned.

The focus on this article is not to summarize the known features and functionality of SoapUI, but instead focus on lessons learned and best practices which are gathered during extensive usage of SoapUI within a webservices project.

Service-oriented architecture (SOA) and webservices are becoming more and more popular in many IT projects. Exposing your business logic component as a webservice is as simple as adding a few metadata annotations.

Before making webservices available to the public, you need to make sure they function as designed. The common way to do this is by writing functional tests for your webservices. Another reason for writing functional tests is regression, e.g. ‘is everything still working as before?’. If well-designed, all tests should continue to be successful when nothing in the entire domain has been changed and detect impacting changes by indicating non-successful results.

SoapUI makes it very easy to write tests from their graphical user interface (GUI). One can create new test suites, add test cases, and add asserts and validations to test outcomes. In addition, programming skills are not necessarily required to write functional tests. Within the most recent project I worked on all the software testers were using SoapUI for functional testing of the services that were exposed.

The tests written in SoapUI are very manageable; this is important because tests need to be maintained just as your code does. Once you download and install SoapUI, you can have functional tests up and running in minutes.

But if you don’t or occasionally run your tests after the initial implementation (note that this is still better than nothing), it is still rather pointless. Tests should be integrated with your build cycle and should be able to be run without thinking about running it. Why bother doing the same thing over and over again.

SoapUI has all the facilities available for integrating it within you continuous integration (CI) environment by means of a commandline runner.It even allows you to generate Junit reports from the results.

The steps that are required to accomplish this integration are described perfectly within the following tutorials:

1. Functional Web Services Testing Made Easy with SoapUI - Part 1 (http://soa.dzone.com/print/2712)

2. Functional Web Services Testing Made Easy with SoapUI - Part 3 (http://soa.dzone.com/print/2977)

For people which prefer / or are interested in using Groovy, please have a look at part 2 of the JavaLobby article, which primarily focusses on using groovy throughout SoapUI for almost everything (varying from defining your property files to  validation by means of code instead of using xpath/xquery expressions). It can be found here: http://soa.dzone.com/print/2853

Best practices / lessons learned

Within part II of this article the following topics will be discussed in more detail:

1. Tips for an optimized SoapUI configuration when using a CM (configuration management) system

2. Tips for creating SoapUI TestCases

3. Tips for setting up the SoapUI Testrunner script

4. Tips for configuring SoapUI within Hudson (CI environment)

Met vriendelijke groet,
Michel Christianen