Forum Discussion

JoostDG's avatar
JoostDG
Frequent Contributor
5 years ago
Solved

(bug?) - json path match assertion with wildcards 'select from current' results in failure

Hi,

When I "select from current" in a JSON path match assertion the assertion actually fails.

 

The field in JSON looks like this:

"field" : "targetOffice"

The select from current sets the assertion to  "targetOffice" (including the double quotes), while actual value is asserted as targetOffice.

 

 

////Update: Wildcard enabled should be ticked. When unticked it's fine. This is not a specific 3.0 issue. Modified the subject line to rectify this.

 

Assertions
  • JoostDG's avatar
    JoostDG
    5 years ago

    No, that wasn't the difference.

    But that showed me in the right direction, so thank you AlexKaras .

     

    It is actually the "allow wildcards" check that explains the behaviour. Nothing to do with the v2.8 vs 3.0, sorry for bringing that up. I never thought allowing wild cards would make the assertion fail. No valid reason for that in my view, so I guess it stays a bug :-)

     

            <con:assertion type="JsonPath Match" name="Match content of [field] smartbear bug - https://community.smartbear.com/t5/SoapUI-Pro/V3-0-bug-json-path-match-assertion-select-from-current-results/m-p/193622#M44379" id="652853cc-94e3-4003-ac79-85af27bf5d60" disabled="true">
          <con:configuration>
            <path>$['errors'][0]['field']</path>
            <content>"targetOffice"</content>
            <allowWildcards>true</allowWildcards>
            <ignoreNamspaceDifferences>false</ignoreNamspaceDifferences>
            <ignoreComments>false</ignoreComments>
          </con:configuration>
        </con:assertion>
        <con:assertion type="JsonPath Match" id="11a67e54-d8a4-4fe8-924a-67690f6364af" name="Match content of [field]">
          <con:configuration>
            <path>$['errors'][0]['field']</path>
            <content>"targetOffice"</content>
            <allowWildcards>false</allowWildcards>
            <ignoreNamspaceDifferences>false</ignoreNamspaceDifferences>
            <ignoreComments>false</ignoreComments>
          </con:configuration>
        </con:assertion>

6 Replies

Sort By
  • richie's avatar
    richie
    Community Hero
    5 years ago
    Hry JoostDG,

    This seems very similar to an issue someone else raised maybe 6 to 8 weeks ago where the string type was maintained in assertion when it wasn't before. I'm typing this out on my phone so cant find the relevsnt post.

    Whatever it looks like a couple of issues (that youve posted on) have been introduced with the latest version. Id raise a service ticket with Smartbear as theyll need to know if they dont already.

    I got no other help for you im afraid!

    Ta

    Rich
    • JoostDG's avatar
      JoostDG
      Frequent Contributor
      5 years ago

      Thanks Richie.

      Support request Case 00413341 logged. 

  • nmrao's avatar
    nmrao
    Champion Level 3
    5 years ago
    Please try append [0] at the end in the JSONPath Expression and see.
    • JoostDG's avatar
      JoostDG
      Frequent Contributor
      5 years ago

      Hi Nmrao. No difference with appended [0].

       

      What I do notice: This is specifically for an assertion that was already created in version before 3.0. Basically, this test step is a copy paste of a step created in 2.8. I just wanted to update that existing assertion for jsonPath $['errors'][0]['field'] with the correct value. That gave me above error.

      When I add the same assertion again to the test step via add assertion - for content I get proposed the same json path, $['errors'][0]['field'] ... but there the proposed expected result is correct (also when I update it from Select From Current). 

      All other assertions I created in 2.8 are still valid. So I guess thise lowers the severity/priority, but it still is curious how 2 exactly the same json path assertions behave differently... 

       

      See posts below... nothing to do with v2.8 v3.0. It is just the wild card enabling that causes this behaviour...

       

      • AlexKaras's avatar
        AlexKaras
        Champion Level 3
        5 years ago

        Hi,

         

        Just a wild guess that expression from 2.8 contains some not visible character that matters during the match.

        Wonder what if you look into your project file using some text editor (e.g. Notepad++) with special characters display option turned on?