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! :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.
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.
Non-Composite Project
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
Composite Project
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 :-)
