mmben commented on issue #5734: URL: https://github.com/apache/jmeter/issues/5734#issuecomment-1322284508
Hi Felix, thanks for your quick response. I've tried provide you a sample of the described behavior. The attached plan contains 4 calls to the github API. Each request is the same. All four calls use a Response-Assertion that checks the return code only and a JSON-Assertion that checks a property within the response. The first two calls (A + B) should have a failing response code assertion as they expect 500, which should not happen. The last two calls (C + D) should have a failing JSON-Assertion, since I put an arbitrary value that will not exist. The order of Response-Assertion and JSON-Assertion is switched between A + B and C + D. The Expected result is that all four requests have a failing assertion and should therefore fail. But case C will only have a failing JSON-Assertion, while the request is still marked as succeeded. While playing around with it, I noticed that I can get that request to be marked as failed too, when I change the `ignore status` flag of the Response-Assertion next to it. Ok, strictly seen, in my test example, the `ignore status` flag doesn't need to be checked, because the response code is `200`, thus it won't fail it. But in a scenario where I want to test the contents of a JSON response where the expected code is 400, it would need to have it checked. I understood the `ignore status` switch to be scoped to what is defined by the Response-Assertion only without affecting other Assertions. What do you think? [Sample_5734.zip](https://github.com/apache/jmeter/files/10057894/Sample_5734.zip) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@jmeter.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
