3

We use Ready API (the commercialized version of SOAP UI) to develop our Automated Test Suite. However, even the smallest change in the UI will cause a mass changes on the xml test suits.

For example, simply load the project "Core". Git diff give us:

Before:

<con:project status="CLOSED" name="_Core">Core-abc-project</con:project>
<con:project status="CLOSED" name="_EU">EU-abc-project</con:project>
<con:project status="CLOSED" name="_US">US-abc-project</con:project>

After:

<con:project name="_Core">Core-abc-project</con:project>
<con:project status="CLOSED" name="_EU">EU-abc-project</con:project>
<con:project status="CLOSED" name="_US">US-abc-project</con:project>

That is not to mention the dreaded lastOpend.

I know we are not alone, as there are discussions here and here.

Here is the things that we did:

  1. Make the project composite, to avoid multiple tests working on the same module

  2. Use "Pretty Print" our XML

  3. Setup excel-cmp to compare our Excel files in Git

It almost drives us crazy to merge pages after pages of xml conflicts, while the editor almost do nothing. Is there any way to further reduce these merge conflicts?

Hoàng Long
  • 10,746
  • 20
  • 75
  • 124
  • Are these really merge conflicts? Did you make different changes on these lines of code in your own fork? A merge conflict will only happen when two different branches change the same line (or lines) of code in different ways? When the lines change on one branch but not on another, there is no conflict. – Code-Apprentice Jun 20 '18 at 15:00
  • Yes, we have several QAs working on the same code base. And when even the smallest change (eg: you click to open a file) causes changes in the XML configurtion, it is VERY easy to get conflicts. Even if there is no conflict (eg: the changes are in *different project*, the mass changes also pollute git diff too – Hoàng Long Jun 21 '18 at 07:35

1 Answers1

2

I've had the same issues on all my soapUI projects and on other projects using generated XML, for example TIBCO. It's painful and dangerous to merge changes and also to find out what was a generated change and what was a user change.

For soapUI, you've probably already done as much as you can: using composite projects to limit the scope of the change and turning on the pretty-print option. Some other suggestions:

  • Keep your project files small and limited to a discrete set of test cases.
  • Invest in a good compare tool like Beyond Compare

Although, on my teams we added another SOP: call out loudly "I'm in the XXX soapUI project file. Nobody touch it until I commit".

craigcaulfield
  • 3,381
  • 10
  • 32
  • 40
  • Thanks for the support. Too bad I had hoped for more... Every time we need to backtrack something, everyone says "man, we are in the mud now" – Hoàng Long Jun 21 '18 at 07:38