Forum Discussion

Cleo-Juniper's avatar
Cleo-Juniper
New Contributor
8 months ago

Is it possible to split up your project.xml file into lost of smaller testsuite.xml files?

We want to keep our SoapUI tests in git.  However with a large team all contributing to one xml file, this is going to cause merge hell for those of us who aren't native xml parsers (ie quite a few of us).

 

Is it possible to split up the one enormous project.xml file into lots of smaller testsuite.xml files which would still display as being part of the same project in the UI?

 

So instead of 

project.xml containing myproject, testsuite1, testsuite2, testsuite3

it would be

project.xml containing a reference to testsuite1.xml, testsuite2.xml, testsuite3.xml 

 

That way multiple people could be working on different test suites with no merge conflicts.

 

2 Replies

  • Hello Cleo-Juniper,

     

    No can do...  SoapUI Open Source must have some limitations to be free.  🙂

     

    The upgrade to ReadyAPI is the way to overcome that.  An alternative is to divide the monolithic project into parts creatively (i.e. break project down by suites into their own project files to make it a little more granular).  If your group can write groovy, break out test cases in to scripts in a script library where the files are naturally broken apart from the project.

     

    If you have a large department, you might consider the trade off between purchase of ReadyAPI or the time it takes to make a band-aid solution work with open source. 

     

    Regards,

    Todd

  • JuZ0's avatar
    JuZ0
    Contributor

    It is totally possible to code a separate tool that would split a single soapui project file to a multiple files structure for GIT. Also this tool would compose multiple files to a single SoapUI project file.

     

    This tool can be done in plain Java for example. SoapUI project XML is easy to split since interfaces and testsuites are in their own separate elements that can be gathered and outputted to separate files as is without any further processing. You would just handle the XML structure.

    You could go further down and even separate TestCases and TestSteps in separate files, but I would suggest starting from TestSuites. TestSuites already offer a good separation and if for some reason multiple people are working with same testsuite XML, conflicts are much easier to resolve compared to resolving conflicts within possibly large SoapUI project XML

     

    General structure of decomposed project stucture would be:

     

    - ProjectFolder

      - interfaces

         - orderfile.txt

         - interface1_<guid>.xml

         - interface2_<guid>.xml 

      - testsuites

         - orderfile.txt

         - testsuite1_<guid>.xml

         - testsuite2_<guid>.xml

      - project_<guid>.xml

     

    The <guid> in the name is the "id" attribute available in SoapUI XML elements:

    - con:soapui-project

    - con:interface

    - con:testSuite

     

    orderfile.txt is a file that keeps track the order of the testsuites and interfaces in the project XML. In project XML the physical order of these elements tells in which order they are shown in the UI. There is no any separate order attribute that would do such a thing. That is why it could be good idea to use order file. In the order file you could for example include those <guid> identifiers in specific order. This would then allow tool to combine and put those elements in correct order when composing a single project file XML from multiple files.

     

    So basically this tool would go through SoapUI project XML and then split from the project XML each of following elements

    - con:interface

    - con:testSuite

    And put them to a separate file in folder structure accordingly.