Forum Discussion

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
},
"status": "success",
"code": "200",
"message": "Operation success",
"version": "2"
}

I setup a Content Assertion on the response to validate that the fields exist:

I can run this call any number of times back to back and the message content assertion will always pass.

However, when I run the entire Test Suite and the same step is run the message content assertion will always fail. It will give an error as if it were trying to find null nodes in the response (shown below)

Any idea or insight into why this is happening? Is there any way to prevent this? Currently I am removing the contract assertion from the test case but that kind of defeats the purpose of the test.

assert

assertion

message content assertion

null

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.

12 Replies

nmrao
Champion Level 3
5 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
  Occasional Contributor
  5 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
  Occasional Contributor
  5 years ago
  - richie
    Community Hero
    5 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