Forum Discussion

jrforeman's avatar
Occasional Contributor
3 years ago

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

Why does ReadyAPI change how it stores a blank XML tag from, say


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


  • 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. ğŸ˜ž


7 Replies

  • nmrao's avatar
    Champion Level 3
    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's avatar
      Occasional Contributor



      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's avatar
        Occasional Contributor

        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?