How to prevent ReadyAPI from randomly changing how it stores empty XML elements?

[jrforeman]

Why does ReadyAPI change how it stores a blank XML tag from, say
<con:properties/>
to
<con:properties></con:properties>

If I make one change and save, I may see many of these differences, which complicates review of the code.
I see this in projects where Composite project is false, and in projects where it is true.

The representation of blank XML elements is one of many things about how ReadyAPI stores a project that seem to change at random with each new version or sometimes randomly within the same version.

I have tried setting the flag "Pretty prints project files", but this is not sufficient to stop this noise.

Is there some other flag I can set so that the method for encoding the project doesn't obscure actual logic changes when I look at the differences? Preferably something that gets remembered in the project, rather than depending on a user setting?

References: The following are a few postings that seem relevant, but don't clean up the random XML representations.

"Version control - Diff is very confusing for ReadyAPI projects?" https://community.smartbear.com/t5/API-Functional-Security-Testing/Version-control-Diff-is-very-conf...
- Answer: Yes, currently, if you change one thing in ReadyAPI, several things in different places of the project might change as well.

"How do I minimize merge conflicts in a ReadyApi composite project when working as part of a team?" https://community.smartbear.com/t5/API-Functional-Security-Testing/How-do-I-minimize-merge-conflicts...
- No accepted answer
- Recommendation to check the flag "Pretty prints project files"

"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."

[nmrao]

Would you please clarify the below for better understanding?
Does happen for entire project or for XML requests?

Are you using a simple project or complex?

Completely understand the changes to be pushed to repo.

[mkrausem]

Hi,

please try to reproduce it and raise an issue in the customer portal.

I raised some issues and most of them could be reproduced and later fixed by the team.

My problem: I tried to reproduce this also but it fails on my machine.

Kind Regards, Michael

[jrforeman]

To reproduce this, I think you have to have a project that you import through multiple versions of ReadyAPI. Here's how I imagine reproducing it, but it will take me more time than I have.

1. Open ReadyAPI. Create a project with a test case that has a properties step, populate that step with at least one property with a name and a value. Save the project, then clear the properties values from the properties steps, so that all that remains is the property name and blank value, and save again. Close ReadyAPI.

2. Upgrade ReadyAPI.  Open project, populate the properties step again; save; clear properties values. We should be back at the original state again after you save and exit ReadyAPI.  But in some versions of ReadyAPI, the way it saves unpopulated properties will differ, as described in the original post.

I have not been able to chase this down further.  Is the ReadyAPI upgrade really the key, or is there some undefined export behavior that may change the XML for an empty element from '<myTag></myTag>' to '<myTag/>' even within the same version of ReadyAPI?

[mkrausem]

Hi,

I decided for my team that everone has to use the same version (and with same configuration)

This was our "solution"

Kind Regards, Michael

[jrforeman · Accepted solution]

So the solution really is: You can't prevent it. Whenever you upgrade, the new version of ReadyAPI will do whatever it wants with regard to the empty XML fields... some versions will generate a beginning tag and end tag <tag></tag>, then the next version may decide to use the shortcut <tag/>, and the version after that may revert to the expanded <tag></tag> again, and there is nothing to be done but allow it. 😞

[JoostDG]

Hi @jrforeman .

Have you tried the relatively new feature of "store locally" for the testSuite/testCase properties, that is available as of v.3.6. (see https://support.smartbear.com/readyapi/docs/testing/properties/local-properties.html) ?

I can't say how it works with the empty fields over different versions, and obviously it's only for the <properties> tags, but it * might * help (no gurantee). 

If you want to apply it to an existing project, here's a save script that can help set all these properties to "save locally" at once:

https://community.smartbear.com/t5/ReadyAPI-Questions/How-to-set-quot-store-locally-quot-to-default-...

Disclaimer: Executing this script does mean you do not want any "hardcoded" testSuite/testCase properties directly in those properties menus. (You can still change/set them via e.g. a setup script).

[jrforeman]

Hey @JoostDG!

Setting properties locally sounds like an useful feature.  Moving properties out of the project source would be a good way to avoid properties value changes that happen during each run, something I have done until now by using cleanup scripts. 

The properties I'm talking about are mostly (all?) in properties test steps, which unfortunately don't offer any way to store locally.  Not sure it is worth the hassle to retrofit existing projects, though that script should help!  I will play with this local storage idea in new projects, and I may change my pattern for setting up test properties in the future to use property types that support storage in the user-local workspace.  Thanks for alerting me to the local storage option!

JR