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

[JoostDG]

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.

[richie]

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]

Thanks Richie.

Support request Case 00413341 logged. 

[nmrao]

Please try append [0] at the end in the JSONPath Expression and see.

[JoostDG]

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]

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?

[JoostDG · Accepted solution]

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>