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?
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 🙂
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.
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! 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.
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.
You shouldn't need to convert back to non composite to run via TestRunner (how we and I assume you are running from Jenkins). I ran a quick test to double check, first I created a new project and ran via the command line, and then converted to composite (deleting the old non-composite XML file) and then ran again, adjusting the command line to point at the directory and all worked fine.
command: cmd.exe /C testrunner.bat "-sTestSuite 1" "-cTestCase 1" "-RTestCase Report" "-EDefault environment" C:\Users\xxxxxxx\AdHoc-ReadyAPI\Project-CLI-Test-soapui-project.xml
command: cmd.exe /C testrunner.bat "-sTestSuite 1" "-cTestCase 1" "-RTestCase Report" "-EDefault environment" C:\Users\xxxxxxx\AdHoc-ReadyAPI\Project-CLI-Test-soapui-project
Note: I generated and ran these command lines with the the TestRunner GUI.
My only real comment about with composite projects is I would use at least Ready API 1.8, as looking at the release notes, there were lots of composite project fixes.
I guess it would be strange for some to hear that we are not using TestRunner. I've seen from a SmartBear webinar that Temil(if I recall it correctly) copy the line with test runner definitions from SoapUI and pasted it on a file. However, the file being used is .bat so I supposed it's Windows Batch file. I was told by my seniors that batch files are slower so we decided to use Maven instead since it will be faster and we were able to load it at Jenkins which was what was required from us. I've used Ready!API 1.9 trial before. I think early this year, but I haven't used it with a composite project that time since that time, one just informs the other that he has some modifications so he will do a commit first. A give and take with Git. Those were the days. If they already had it fixed then that would be great 🙂
Ahh... I always forget people running with Maven, probably because I don't have experience with it, sorry for any confusion caused.
We also face this issue, so we setup some rules to follow to avoid merge.
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