Forum Discussion

forrestvenable's avatar
forrestvenable
Occasional Visitor
7 years ago

How do I minimize merge conflicts in a ReadyApi composite project when working as part of a team?

A coworker and I are working on testing an API with ReadyAPI and SoapUI NG. We are collaborating using git and have set the project to be composite. There is an expectation that we will use feature branches and merge into a non-master branch.

We have found that just about any changes will inevitably create merge conflicts among a bunch of files. In one particularly bad example this has resulted in 30 files having conflicts, but five or six files having problems is virtually guaranteed. Fixing the conflicts in the non-xml files is fairly simple, but fixing xml files by hand is difficult and parts of what we are working on regularly disappears. Presumably this is due to us poorly handling these merge conflicts.

What are the best practices to minimizing the number of merge conflicts we are creating and resolving them when they occur?

12 Replies

Sort By
  • bch's avatar
    bch
    Occasional Contributor
    7 years ago

    Hi,

     

    We also face this issue, so we setup some rules to follow to avoid merge.

     

    1. Never ever save your Project by pressing Ctrl+S, instead of that save a particular test by right click on test --> Composite Actions --> Save TestCase
    2. If any new properties added to Test Suite then add them manually by updating relevant Settings.xml
      • Open Setting-xml in Notepad Editor and add new property node as shown below.
      •  <con:properties><con:property>
              <con:name>key</con:name>
              <con:value>value</con:value>
           </con:property>
        </con:properties>
    3. Similar approach for Project level properties, add them manually by opening settings.xml in notepad++ editor and then save
    4. Addition of new tests should be also added to element.order manually and save

     

    by performing above rule we only commit intended changes by us.

    We are not getting any surprises of lot file changes which Ready API does in BackGround when you press Ctrl+S.

     

    This is working fine for us, and yes all our members are having same settings (like pretty print enable)

     

    I hope this helps

     

    Kind regards

    Bch

  • Radford's avatar
    Radford
    Super Contributor
    7 years ago

    While I don't use Git (I use SVN), in addition to using composite projects I found that to get maximum benefit from diffs I had to make sure that the "Pretty print project files" preference was set. For some (I guess historical) reason, this setting is on the WSDL preferences page:

     

    While this allows you to see exactly what has changed when diff-ing versions, it does have the problem that this is an application setting, thus you have to make sure all users set this value manually on their copies of ReadyAPI (If a user does not set this in their copy ReadyAPI it will revert to saving on a single line). Ideally I would like to see this as a project setting.

     

    Debz, I believe that when converting to a composite project, the old XML file is left and is no longer updated, once I'm happy with the conversion I always delete this file to avoid confusion.

     

    • Debz's avatar
      Debz
      Contributor
      7 years ago

      Hi, I've forgotten about that "pretty print" option. It's good that you mentioned it. Another co-worker set that up on our end. It makes comparison on the XML level a lot easier. For the XML, I see. I thought it was still being used somehow LOL. Thanks Mate! :smileyhappy: I was initially loading it, and kept on seeing "Composite Project: False", then someone said it should have been the whole folder instead. So from then on, we just tell everyone working on the project to load the whole folder.

      • Debz's avatar
        Debz
        Contributor
        7 years ago

        By the way, if you'll be running your tests on a CI environment like Jenkins, save the release version(after everyone has already integrated their features or changes) as a non-composite version. Another issue we've encountered before is that Jenkins wasn't able to see the XML file it needed to run when the project was saved as a composite project.

  • nmrao's avatar
    nmrao
    Champion Level 3
    7 years ago
    Not much idea about composite projects.

    There is a tool called "Meld" which does compare (3 way comparison)
    - files
    - directories
    - repositories (svn, git etc)

    Try to see if it helps better managing working copies & merging & resolve conflicts etc.,
    • Debz's avatar
      Debz
      Contributor
      7 years ago

      We've also encountered merge conflicts on our project. It's daunting to fix merge conflicts line by line especially if most team members you have do not come from a developer background, so I suggested we use "composite" project option. When you use composite, make sure that on loading the project at SoapUI, you select the main folder, and not the XML file. Otherwise, the one you are loading will show "Composite Project: False" when you check the Project Properties. As far as I know, when you save a composite project, different folders will be created per test suite so we were able to avoid merge conflicts since one person works on one test suite while another works on a different suite or resource so even if they work on the same time, conflicts were avoided (we are working on separate folders and files now, instead of one whole XML which generated the conflict before).

       

      Another option I've been told is to use gitignore so that whatever changes others make to one file will be disregarded by my changes but  I haven't tried that one yet. I'm also still new with SoapUI and Git :-)

  • larsn's avatar
    larsn
    Contributor
    7 years ago

    As others have posted, use "pretty print project" setting and composite projects - these will make understanding the changes a lot easier. I would add using .csv files for data sources instead of .xls which are binary files. 

     

    I would add that if you are doing groovy scripting, then store dynamic data in the context object instead of in a property. You can still access it in a later test step in the test case but that data won't be saved to the project.xml.