How do I minimize merge conflicts in a ReadyApi composite project when working as part of a team?
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@Radford wrote:Ahh... I always forget people running with Maven, probably because I don't have experience with it, sorry for any confusion caused.
No worries. I haven't had any experience with it before this job so I've also looked around the forums/community for some setup details. I've also asked about it during the webinar but I wasn't able to get a clear answer. I guess I'm just lucky that I got to work with another senior tester who was able to figure it out
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I tried to come up with some tips to mitigate conflicts, please see here:

- « Previous
-
- 1
- 2
- Next »
- « Previous
-
- 1
- 2
- Next »