Working collaboratively on SoapUI projects

Some rules and procedures to avoid merge conflicts when working on SoapUI projects with more than one person.
created by on 2013-07-17

In order to collaboratively work on a SoapUI project which is checked into a git repository (or any other version control system) you must follow a few simple rules to make merging easier and to keep changes trackable.

This tutorial will show you how you can accomplish this with git and SourceTree on a Windows environment. But the process can also be applied to other environments.


  1. Install SoapUI
  2. Install git
  3. Install SourceTree

Enable Pretty Printing for the SoapUI Project files

In order to make merges as easy as possible you must enable pretty printing for your SoapUI project files – because otherwise SoapUI will create stupendiously long lines which can never be savely merged.

For example a SoapUI project file which does not use pretty printing looks like this:

Screenshot of a SoapUI Project file which does not use pretty printing

It is impossible for any line based version control system to reasonably detect changes to a line which is 8000 characters long. So the idea is to make break long lines into seperate lines before checking in changes.

To enable pretty printing for SoapUI project files goto to your soapUI preferences and check the following options in the WSDL Settings section.

Goto File > Preferences > WSDL Settings and check these options:

  1. Pretty Print
  2. Pretty Print Project Files
  3. Trim WSDL

Screenshot: SoapUI Preferences Dialog for enabling pretty printing

Enable pretty printing for SoapUI projects

Project file normalization

Besides enabling pretty printing you can further reduce the risk of running into merge conflicts by noramalizing the XML of the SoapUI project file before committing it.

The normalization process

In order to normalize a SoapUI project file (or any other XML file for that matter) you should perform the following steps for all lines of the file:

  1. Pretty print the XML (this is done by SoapUI itself)
  2. Remove leading and trailing spaces or tabs on each line
  3. Replace all session ids which have been added by SoapUI while running the test cases
  4. Remove empty lines

The normalization tool

Because all steps for normalizing a SoapUI project file mentioned above (except for the pretty printing) you need to utilize an external tool for this.

I have written a small tool called “soapui-project-normalization” for this which can be used on all platforms alike:


# !/bin/bash


# Normalize the project file
./soapui-project-normalization $inputfile > $tempfile
cp $tempfile $inputfile
rm $tempfile


set inputfile=".\soapui-project.xml"
set tempfile=".\temp.xml"

.\soapui-project-normalization.exe %inputfile% > %tempfile%
copy %tempfile% %inputfile%
del %tempfile%
Normalizing a SoapUI project file

The Development process (in SourceTree)

Pull changes from the remote master

Before you start working on a new feature you should always pull the lastest changes from your remote master.

Pull changes from a remote master (with SourceTree)

Implement a new feature

A new feature should (ideally) be based on the latest version of the remote branch and should be developed in a separate feature branch.

The whole process has the following seven steps:

  1. Pull from your remote master (to make sure you are basing your changes on the latest version of the project)
  2. Create new branch for the new feature
  3. Add and test your changes
  4. Normalize the project file
  5. Commit your changes to your feature branch
  6. Switch back to master
  7. Pull changes from the remote master
  8. Merge the new feature branch into master
  9. Push change to remote master

To avoid conflict you should make sure that your coworkers are not making changes to the same sections of the project file than you.

Creating a new feature

Switching branches

… or switching between commits can be very helpful when for example you want to

Switching between commits with SourceTree
Fork allmark on GitHub