Forum Discussion

sjcurt01's avatar
sjcurt01
New Contributor
3 years ago

Is 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 are not present.  This is accomplished using either a JsonPath Existence Match assertion checking for a value of false or with a JsonPath 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?

2 Replies

Sort By
  • richie's avatar
    richie
    Community Hero
    3 years ago
    Hey sjcurt01,

    Ive just had a look at the release notes for v5.7.0 and the json libraries have been updated to jayway jsonpath v2.4.0.

    Im guessing thats the problem. Checkout the changes in jayway v2.4.0 and that'll give you the answers you need i reckon

    Cheers

    Rich
    • sjcurt01's avatar
      sjcurt01
      New Contributor
      3 years ago

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