Forum Discussion

RBlack's avatar
RBlack
Occasional Contributor
6 years ago

Removing breakPoint elements from test case XML files

We have a lot of SoapUI test cases that have accumulated many <breakPoints> elements in their test case XML files as different users have debugged through the test cases on various occasions over many months.  Some test cases have hundreds of such breakpoints, which are now irrelevant.

 

Is it safe to simply remove the <con:breakPoints>...</con:breakPoints> elements from the test case XML files?  This can be done in a bulk operation over large numbers of tests, much more efficiently than having individuals edit the tests in ReadyAPI and remove the breakpoints manually.

 

Appreciate any insights on this.  Thanks.

 

Rob

4 Replies

  • richie's avatar
    richie
    Community Hero

    Hi,

     

    Are you talking about editing the Project .xml file by doing say a find and replace to remove the tags you are talking about?

     

    If you are I need to warn you of one thing which totally caught me out when I did something similar.

     

    For a particular SoapUI Project, I had a testdata file that was in ISO-8859-1 format.  Within the file I had some characters from the ISO-8859-1 charset that were NOT supported by UTF-8.  Obviously the project .xml file holds all the testdata referenced in your test cases.

     

    Once I'd made the find and replace change (the reason I was editing the file) and then attempted to re-open the project file in ReadyAPI! - I couldn't open the file - the file wasn't considered 'wellformed' anymore due to the 'illegal' character.  I also couldn't open the file in XMLSpy, etc.

     

    I had to find the 'illegal' character via Notepad++ and remove the character - replacing it with a char that was supported by ISO-8859-1 AND UTF-8 before the file was 'wellformed'.  Once the file was wellformed I could then open the project in ReadyAPI!

     

    It was a LOT of work finding the dodgy character

     

    After reading your post again - I don't think you are talking about manually editing the project .xml file - but the overall advice still stands as you are talking about xml.  Ensure if you are editing the .xml files that they are wellformed relative to the charset you are specifying - otherwise SoapUI won't like it.

     

    Cheers,

     

    richie

  • RBlack's avatar
    RBlack
    Occasional Contributor

    Hi richie.  Indeed I am considering writing a script to load the test case XML files and write them back to disk with the <breakPoints> elements removed.  Basically automating the effect of editing the XML file in Notepad++, deleting the <breakPoints> elements and saving the file, but for hundreds of files not a few.

     

    You are right to warn about the character set - I've had issues with scripts loading/saving test case XML files in the past, where I neglected to load as UTF-8 and got strange characters when saving back to disk.  Thanks for the reminder!

     

    So I will try doing this at some point, not sure how soon (busy with other things).  But will remember to explicitly specify the charset when saving and loading.

     

    Thanks,

     

    Rob

  • nmrao's avatar
    nmrao
    Champion Level 3
    RBlack, is it still the case i.e., the execution gets interrupted by break points, even when the tests are executed using testrunner(.bat/.sh) utility or if you launch it by right click? I hope not.
    • RBlack's avatar
      RBlack
      Occasional Contributor

      Hi nmrao.  Fortunately tests execution via testrunner.bat is not affected by breakpoints.  The problem to be solved is simply that the accumulated breakpoints take up more and more space in the test XML files - sometimes there are more lines for breakpoints than anything else in the test!  Just looking to ensure that it is okay to remove them from the XML files (via scripts), rather than somehow removing them via the ReadyAPI IDE.  (On that point, it looks like <breakPoint> XML elements remain in the XML file even after the breakpoints are removed in the IDE).