Contributions
SoapUI project file XML format
We have a SoapUI project file in our git repository that we try to code review when changed. SoapUI has always saved it's project file without any formal XML formatting rules that I can infer from it's behavior. I've recently tried using xmllint --format before committing changes to allow for git diffs to be reasonable when changes are made to the project file, but have found some odd behavior in how SoapUI handles it's XML project file format. HTTP Request headers have some of their XML characters converted to HTML entities in the SoapUI project file: <xml-fragment xmlns:con="http://eviware.com/soapui/config"> <con:entry key="foo2" value="bar2"/> <con:entry key="foo1" value="bar1"/> </xml-fragment> I'm not sure why the xml-fragment tag is even necessary, but I would expect the above snippet to look more like: <xml-fragment xmlns:con="http://eviware.com/soapui/config"> <con:entry key="foo2" value="bar2"/> <con:entry key="foo1" value="bar1"/> </xml-fragment> And ideally, it would just contain: <con:entry key="foo2" value="bar2"/> <con:entry key="foo1" value="bar1"/> But neither of the snippets I expect result in HTML request headers being set in the request. They get purged immediately on project load by SoapUI. Is the observed behavior something that can be changed with a setting, or observed by someone else due to some environment issue? Thanks, Steve362Views0likes0CommentsRe: Is JSON nonexistence a regression error in SoapUI 5.7.0?
Unfortunately, it hasn't answered my question. I understand that the behavior of SoapUI may have changed due to a change in the behavior of an underlying library, but isn't that exactly the point? Shouldn't SoapUI's behavior remain consistent with the expectations of the user even when underlying library behavior changes? To say that a contract with a SoapUI user must be broken just because a dependency changed doesn't make any sense. To me being one of SoapUI's users, a JSON path existence test should respond with "false" for a JSON path that does not exist. To say that because the JSON library's behavior changed necessarily means that expectations must not be met doesn't make sense to me. In this particular case, it seems that a try { } catch (Exception e) { } should surround the library function, with the SoapUI assertion returning "false" is more appropriate than just blaming the library for SoapUI's regression error. - Steve459Views0likes0CommentsIs JSON nonexistence a regression error in SoapUI 5.7.0?
I've seen several posts in different forums about a change in behavior that I've experienced myself at least between SoapUI 5.4.0 and the latest SoapUI 5.7.0. I have several test cases with assertions validating that elements in a JSON payload arenot present. This is accomplished using either aJsonPath Existence Match assertion checking for a value of false or with aJsonPath Count assertion checking for a value of 0. But in SoapUI 5.7.0, checking for a JSON path that does not exist produces an error internally without checking anything. I've seen one viable workaround in which the internal XML representation of the payload can be validated with the exists() XPath XQuery function, but the point is the regression in behavior. SoapUI 5.4.0 successfully performs both types of JSON assertions for nonexistence. My SoapUI project has many such assertions and has proven very difficult to automate the migration from JSON assertions to XPath assertions. How is this change in behavior not a regression error, and if it is, should I log a bug against SoapUI 5.7.0?522Views0likes2Comments