Forum Discussion

shales's avatar
shales
Occasional Contributor
5 years ago
Solved

Message Content Assertion: Assertion is looking for null fields even though it worked previously

When I run my call I get the following JSON object: { "data": { "id": 159, "zoneName": "NameofZone", "createdAt": "2019-09-11 19:25:31", "updatedAt": "2019-09-11 19:25:31", "groupsId": null ...
assert
assertion
message content assertion
null
  • shales's avatar
    shales
    5 years ago

    The dev team got back to me today.  The issue is with the URL.  Since this is a call that requires a template parameter for the ID, when the assert is created it is created with the ID in the URL.  When I run the test from the test suite level, a new group is created, thus a new group ID is created which does not match the ID listed in the URL for the content assert.  Below is the direct reply from the team:

    Message Content Assertion is based on xml object and it converts all json nodes into xml nodes and declares namespace ns1=endpoint.
    When the assertion was created the endpoint was http://{APIURL}/api/zones/165.
    If you open XML tab in the response you will see something like <Response xmlns="http://{APIURL}/api/zones/179">. And the namespase for the got response and in the assertion are different, that's why the assertion fails.
    The node cannot be found at all

    They suggested to substitute the assertion for the JSONPath Existence Match which is more preferable for json responses and independent of endpoint.


shales's avatar
shales
Occasional Contributor

Still thinking about this.  Since the content assertion passes when I first configure it and it passes until I run my entire test suite which includes several calls before the one in question.  Those calls also use content assertions but their responses do not contain a nested object.  Is it possible that the content assertion for the failing tests is using cached schemas from the previous runs?  I'm just brainstorming here as I am not entirely sure how the assertions work under the hood.  It is odd that the failing tests will pass when run seperately then fail when the test case is run.  It's important to note that once the assertion fails it will always fail until it is reconfigured to the response.  But before it fails I can run the call itself and return a pass for the assertion, I can run a couple of the calls before the failing call then run the failing call and it will pass.  But once I start the test from the Test Suite level when the tests reach the calls in question they fail for the content assertion.  It seems like the way it parses the message may be causing it but it doesn't make sense as to why it would work in the first place.

richie's avatar
richie
Community Hero
5 years ago

Hey shales 

 

I'm actually running v2.7.0 and my Message Content Assertion content is slightly different to yours anyway - but I have another issue thats holding me up so I'm gonna need to upgrade to v2.8.0 - so if I get a chance I'll try and replicate what you've got.

 

As far as I'm aware - SoapUI only caches properties and .wsdls, but no assertions - and doesn't cache request response.  However - if you say it works when you've initially configured the Message Content Assertion but stops after so many requests - have you checked to see if you have any caching headers on your response that could be interferring? (just a thought - look for pragma and Content-Cache)

 

Anyway - so you're saying it always fails on the TestSuite execution - but if you run the test individually it executes fine?

Can you disable the tests that are above the test in the testsuite and then execute the testsuite?  I'm just wondering if executing at the testsuite level is a bit of a red herring - if you disable the tests above this - at least this might prove either way if some sort of caching is involved?

Or - move the test with the nested attribute in the Message Content Assertion higher in the testcase sequence in the testsuite?

 

I've previously had test steps that failed when executing the testcase or testsuite - but ran fine individually - I added  delay before the relevant teststep and the assertions that failed no longer did so.  Its a bit rubbish to think that just cos you have a nested object in there's a bit more latency causing the assertion to fail - but it's something to investigate just to confirm this isn't the case.

 

Cheers,

 

rich

 

  • shales's avatar
    shales
    Occasional Contributor
    5 years ago

    I've sent my project to SmartBear.  They agree that something isn't right.  They are forwarding the issue to their development team.  The thought is that the nested node that appears in the assertion set-up is causing an issue with the parsing.  I will update the thread when I hear back from them.

    • TanyaYatskovska's avatar
      TanyaYatskovska
      SmartBear Alumni (Retired)
      5 years ago

      Thanks for this investigation, guys!

      shales, we will be waiting for the update from you.

       

      • shales's avatar
        shales
        Occasional Contributor
        5 years ago

        The dev team got back to me today.  The issue is with the URL.  Since this is a call that requires a template parameter for the ID, when the assert is created it is created with the ID in the URL.  When I run the test from the test suite level, a new group is created, thus a new group ID is created which does not match the ID listed in the URL for the content assert.  Below is the direct reply from the team:

        Message Content Assertion is based on xml object and it converts all json nodes into xml nodes and declares namespace ns1=endpoint.
        When the assertion was created the endpoint was http://{APIURL}/api/zones/165.
        If you open XML tab in the response you will see something like <Response xmlns="http://{APIURL}/api/zones/179">. And the namespase for the got response and in the assertion are different, that's why the assertion fails.
        The node cannot be found at all

        They suggested to substitute the assertion for the JSONPath Existence Match which is more preferable for json responses and independent of endpoint.