Forum Discussion

shales's avatar
shales
Occasional Contributor
6 years ago

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


nmrao's avatar
nmrao
Champion Level 3
6 years ago
See how it behaves if you uncheck the checkbox for the response elements where you may expect null. In this case, "groupId".
  • shales's avatar
    shales
    Occasional Contributor
    6 years ago

    nmrao Thank you for your response!  I'm not expecting group ID to be null. I'm expecting all fields to exist and they do, I can see them in the response.  But for some reason the assertion I set changes the fields it expects to exist to null. So even though the response is returning what I want the assertion fails.

     

    I reconfigure the assertion to pass then run the request again and it passes.  I run a couple steps before the test step that fails and the failing test step passes.  But then I start the test from the Test Suite level and the test step fails and all of the fields the assertion was expecting are now changed to null.  I attached a screenshot of the failed assertions with the response next to it so you can see that everything that the assertion expects to exist actually does exist in the response.

  • shales's avatar
    shales
    Occasional Contributor
    6 years ago

    • richie's avatar
      richie
      Community Hero
      6 years ago
      Hi shales,

      I tried reproducing your issue but i couldnt. What version of ReadyAPI! are you running?

      Its not perfect, but you could replace the Message Content Assertion with individual existence and content match assertions which would give you the same resultant as the message content assertion....its just less efficient and more tedious, more work.

      Did i understand correctly....when you execute the test your response generates a payload to assert against but the Message Content Assertion youve setup with existence checks all report as failing despite the fact you can see the attributes in the payload?

      That's weird. Have you tried any of the other verification types in the Message Content Assertion like = or not exists?
      I'm wondering whether the problem is the exist check alone or whether its other verification points too? Also crossed my mind to ensure the underlyinf logic on the exists and not exists check hasnt been switched un the version youre running so the not exists actually executes an exists check underneath...but thats a sloppy defect so wouldnt expect it.
      If you cant find the solution and it sounds like a defect id raise a tech support call with Smartbear, but id try and investigate with the other verification points first to see if theres an identifiable pattern.

      Ta

      Rich
      • shales's avatar
        shales
        Occasional Contributor
        6 years ago

        Thanks richie ,

        I think it has something to do with the way the message content assertion is reading the nested object in the response.

         

        For instance the groupsId shows another nested null field.  This doesn't occur when I input the raw response into a Json Viewer or in the Outline tab of the response.  Here is the response, but the message content assertion window in the screenshots above show a nested null field from the groupsId field.

         

        {
  "data": {
    "id": 163,
    "zoneName": "APIzone",
    "createdAt": "2019-09-13 00:44:42",
    "updatedAt": "2019-09-13 00:44:42",
    "groupsId": null
  },
  "status": "success",
  "code": "200",
  "message": "Operation success",
  "version": "2"
}