Opensphere Blog

Regression Tests on Messaging and Webservice
base for integration projects and SOA initiatives.
Simple and with minimal overhead.

Opensphere in continuous integration

Continuous integration plays a big part in software development. This especially concerns those bigger projects, where tens of people are working on the very same source code. A small change in the implementation can have quite disruptive influence on existing functionality. Believe me; I’ve seen many projects which suffered from that. The time spent on investigating problems with failing basic functionality was an enormous waste of money.

Continuous integration is a must, no question about that, but there are certain scenarios in which it’s hard to implement typical CI solutions. Web services are one of those.

Opensphere - a helping hand

Opensphere as a complete testing framework allows for testing numerous system elements, web services included. When we have the WSDL file ready, implementing test case logic is only a matter of few clicks.

Running integration tests

In a typical continuous integration environment, every change in the source code triggers the continuous integration server which first builds the project using the latest source files and then automatically runs the integration tests. You may wonder how does the Opensphere testing framework fit in that picture. Given its graphical user interface, you probably think that it doesn’t very well. Well it does, all thanks to batch processing.

Batch processing allows executing test suites from the command line. It requires Apache ant, but can be easily adapted to Maven or any other project integration solutions. Running test suites is only a matter of executing ant runOSTest command, but before you do that; there are couple of things you should do.

First, you have to locate the build.xml file - it should be in the bin/batch folder. Second, edit the file to declare which Opensphere projects you want to be executed:

<fileset id="projects" dir="${configurationDir}/projects/yourWebServiceProject"/>
                <include name="yourWebServiceProject.osp" />


And third, define additional properties such as path to the directory where the HTML report will be stored. After including the runOSTest target in your CI environment configuration, you will have your project continuousely tested with each build and errors in your code will appear immediately. The time you save can be used for something much more productive than investigation and fixing functionality that was broken many days before.

Blog tags: 

User login