Contributions
Re: Message Content Assertion: Assertion is looking for null fields even though it worked previously
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.5 years agoPlace ReadyAPI QuestionsReadyAPI Questions2.6KViews0likes1CommentColon (:) is being sent as ascii (%3A) in HTTP Request
I have a timestamp parameter. I need to pass this parameter into a request as a query parameter. When the request runs the colons ( : ) in the time field are converted to ascii (%3A) causing the request to fail. I updated my ReadyAPI settings to use UTF-8 encoding. I am unable to get the request to send the timestamp without converting the colons. Is there a way to prevent the characters from being changed to ascii? Example: The timestamp is:09-23-19T11:41:27 The request passes the timestamp as:09-23-19T11%3A41%3A27Solved8.9KViews0likes1CommentRe: Message Content Assertion: Assertion is looking for null fields even though it worked previously
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.5 years agoPlace ReadyAPI QuestionsReadyAPI Questions2.6KViews0likes3CommentsRe: Message Content Assertion: Assertion is looking for null fields even though it worked previously
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.5 years agoPlace ReadyAPI QuestionsReadyAPI Questions2.7KViews0likes5CommentsRe: Message Content Assertion: Assertion is looking for null fields even though it worked previously
Thanksrichie, 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" }5 years agoPlace ReadyAPI QuestionsReadyAPI Questions2.7KViews0likes7CommentsRe: Message Content Assertion: Assertion is looking for null fields even though it worked previously
nmraoThank 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.5 years agoPlace ReadyAPI QuestionsReadyAPI Questions2.8KViews0likes0CommentsRe: Message Content Assertion: Assertion is looking for null fields even though it worked previously
5 years agoPlace ReadyAPI QuestionsReadyAPI Questions2.8KViews0likes9CommentsMessage 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.Solved3.3KViews0likes12CommentsRe: Getting and Setting a property based on Sibling value
HI Olga, Yes, the issue appeared to be that the request contained too much data and the jsonslurper was running out of memory. We changed the call to a batching call which seems to have resolved our issues.5 years agoPlace ReadyAPI QuestionsReadyAPI Questions1.9KViews0likes0Comments