You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by GitBox <gi...@apache.org> on 2022/11/18 17:14:16 UTC

[GitHub] [jmeter] mmben opened a new issue, #5734: Multiple Assertions per HTTP Request

mmben opened a new issue, #5734:
URL: https://github.com/apache/jmeter/issues/5734

   ### Expected behavior
   
   When adding more than one assertion under an HTTP Request, and one of the assertions fails, the request should be marked as failed, independent of which one of the assertions fails.
   
   ### Actual behavior
   
   The HTTP Request is marked succeeded when the last assertion succeeds. It seems the result of the previous assertions is overridden by the last one.
   
   ### Steps to reproduce the problem
   
   The issue was perfectly described in someone elses bug report from june https://github.com/apache/jmeter/issues/5677.
   For reasons that I could not see, the issue was closed as invalid.
   Yet I run into the same issue. Did I miss something?
   
   ### JMeter Version
   
   5.5
   
   ### Java Version
   
   openjdk version "11.0.11" 2021-04-20
   
   ### OS Version
   
   Windows 11 22H2


-- 
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-unsubscribe@jmeter.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [jmeter] FSchumacher commented on issue #5734: Multiple Assertions per HTTP Request

Posted by GitBox <gi...@apache.org>.
FSchumacher commented on issue #5734:
URL: https://github.com/apache/jmeter/issues/5734#issuecomment-1320860996

   I think, this is intended behaviour, as it allows the assertions to switch a failing request to be OK. The most prominent example for this is the ResponseAssertion, that has the `ignore status` switch for exactly this use case.
   
   That said, I think the referenced issue #5677 was not closed on purpose and the *feature* is surprising to say at least. We should think about how to better support both use cases.


-- 
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-unsubscribe@jmeter.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [jmeter] mmben commented on issue #5734: Multiple Assertions per HTTP Request

Posted by GitBox <gi...@apache.org>.
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-unsubscribe@jmeter.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [jmeter] FSchumacher commented on issue #5734: Multiple Assertions per HTTP Request

Posted by GitBox <gi...@apache.org>.
FSchumacher commented on issue #5734:
URL: https://github.com/apache/jmeter/issues/5734#issuecomment-1320918623

   Can you post a minimal test plan, that exposes the described behaviour?


-- 
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-unsubscribe@jmeter.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [jmeter] mmben commented on issue #5734: Multiple Assertions per HTTP Request

Posted by GitBox <gi...@apache.org>.
mmben commented on issue #5734:
URL: https://github.com/apache/jmeter/issues/5734#issuecomment-1344407939

   Hi Felix,
   just wanted to check back and see, if the sample I provided helped in any way.
   Would be great, if you could hint about it.
   Cheers!


-- 
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-unsubscribe@jmeter.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org