Forum Discussion

pb1's avatar
pb1
Contributor
5 years ago
Solved

JSONPath - negative match alternatives

Hi there.   We are currently trying to assert, that two sibling nodes in a JSON do not have the same value in one of their parameters. For example for the parameter position:   nodes:[{ "na...
  • richie's avatar
    richie
    5 years ago

    Hi pb1 

     

    I don't think there is a native functionality option.  I asked this question about 6 months ago - but the 3 XPATH/XML options I'm aware of didnt work for JSONPATH/JSON.

     

    The only answer I found was to use groovy (which Rao kindly put together for me). 

     

    If someone does come back with a non-groovy answer - great! I'd welcome knowing the option - but for now when I have to do this when the response type is json - I rely on groovy.

     

    I have one other suggestion that 'might' help you get around this that's just popped in my head - so never tried it myself.  Depending on your webservice (for this particular test step which returns json) you could add an Accept header (value = application/xml) - to force the response content type to XML.  Perhaps you could use one of the XML related options using this approach?  I appreciate it wouldn't be the first option you might consider - but if you're really adamant you dont want to try groovy - switching the content to XML for this single test might allow you to get around this?

     

    Hope this helps!......although I suspect it didn't!

     

    Cheers,

     

    rich

     

richie's avatar
richie
Community Hero
5 years ago

Hi pb1 

 

I don't think there is a native functionality option.  I asked this question about 6 months ago - but the 3 XPATH/XML options I'm aware of didnt work for JSONPATH/JSON.

 

The only answer I found was to use groovy (which Rao kindly put together for me). 

 

If someone does come back with a non-groovy answer - great! I'd welcome knowing the option - but for now when I have to do this when the response type is json - I rely on groovy.

 

I have one other suggestion that 'might' help you get around this that's just popped in my head - so never tried it myself.  Depending on your webservice (for this particular test step which returns json) you could add an Accept header (value = application/xml) - to force the response content type to XML.  Perhaps you could use one of the XML related options using this approach?  I appreciate it wouldn't be the first option you might consider - but if you're really adamant you dont want to try groovy - switching the content to XML for this single test might allow you to get around this?

 

Hope this helps!......although I suspect it didn't!

 

Cheers,

 

rich

 

  • pb1's avatar
    pb1
    Contributor
    5 years ago

    Hey richie

     

    Thanks for your answer, I have done some digging myself and was also unable to find anything that doesn't use XPath. Groovy solves this easily and I personally don't mind it but the test-manager in our project has an aversion to code in tests and prefers things to be solved natively in SoapUI - if there are no native solutions provided we will simply use a groovy-script to solve it.

     

    Our services do not allow forcing formats aside from JSON, neat idea though!

    • nmrao's avatar
      nmrao
      Champion Level 3
      5 years ago
      Writing assertions in groovy and executing them in soapUI is integral part.
      No external install of groovy is needed and this should be made clear to the people.
      After all, if assertions couldn't be in place then it is as equal as not tested.
      • pb1's avatar
        pb1
        Contributor
        5 years ago

        The problem does not lie within Groovy itself, but within the fact that there will be code in the tests that need to be maintained. Some of the testers employed have no programming experience and thus will have a harder time reading into and understanding the tests.

         

        When you have an assertion, you expect to be able to either define that some content must match - or must not match - an expected value, that is some basic logical programming and not having it supported natively in JSONPath seems odd to me, hence the question.