Contains-Assertions suddenly not matching any more?!
I am having a very odd bug that suddenly many of my assertions which used to work fine suddenly indicate mismatches even though the responses actually *DO* match. I tried to analyze and boil things down but now I am at a point where I got stuck:
One of my responses contains a nested XML structure describing countries and certain attributes for each. The response in raw view begins with:
<CountryResource><Countries><Country><CountryCode>... (rest omitted for brevity)
To check that I am using a "Contains"-assertion (without options, i.e. both, the ignore-case and regular-expression checkboxes are UNticked!). It just checks for the very begin of the structure, i.e.:
Contains:
<CountryResource><Countries><Country>
But this assertionfails! :smileyfrustrated:
Condensing further I found that up to
Contains:
<CountryResource>
the assertion matches but as soon as I add ONE MORE character:
Contains:
<CountryResource><
the assertion fails!?!
Totally puzzled! Any idea what is going on here and why this does not match? I even copied the text from the response to make sure there are no issues due to different code-pages, character encodings or such. Why does this match for the first element name but not anything beyond?
This is using soapUI 5.2.1 on Windows 8.1
Nevermind! We found the reason!
A colleague of mine had reformatted ("pretty printed") the soapui-project.xml file (for whatever reason...).
Interestingly soapUI had survived the procedure (i.e. the file was still readable) but the formatting of the strings used in the assertions was gone (i.e. all line breaks of assertion strings were lost) and hence the assertions didn't match any more.
While trying to understand why things didn't match anymore, I saw that all comparisson strings were on a single line and hence thought, that one would need to take the raw-string for the comparisson. But one actually needs to take the formatted string instead! If one pastes the formatted string into the assertion's contains-field, then the assertion matches! Due to that I realized that someone must have "flattened" all assertion patterns.
After realizing this and tracing down the "culprit" we reverted to a version just prior before that reformatting and everything was back to normal.
Thanks and regards,
M.
BTW: an observation I did during my analysis: you do funny escaping of XML characters inside token strings!
Only '<' is escaped as < while '>' is not replaced by > as it should. Thus, e.g. "<foo>" as a pattern is stored in your soapUI project file as '...<token><foo></token>...'. This is actually invalid XML, but astonishingly your parser consumes that without problems...
