Ability to fail a test case if unexpected requests are received and code is swallowing exceptions

[ALSaleemALRaedah]

Hello,

A Recent Scenario has required me to create a unit test in which two API calls are mock. One successful one with fake data and another that should cause the test to fail if called for business logic validation. Looking at the documentation I have noticed that its currently not supported. Is there any plans to add such feature?

Thanks.

[Colin-b]

Hello @ALSaleemALRaedah ,

Let me try to rephrase your issue to make sure I understand it properly as it can be interpreted in different ways:

1. You want to mock the response to a specific URL but this URL should be called only once. You want your test case to fail if it was called more than once. The approach for this check is to assert that a single request was issued.

2. You want to mock a response to a specific URL but you want your test to fail if another URL is called. This is already the default behavior as stated in the documentation. Unless your application code is swallowing exceptions, in which case you can still refer to 1) for a solution to this issue.

3. You want to mock 2 responses for 2 requests and one of them should fail in some way depending on your code. Well you are in luck as you can provide any body, headers and/or status code as part of your response. Should your code fail according to those criteria. If you want to simulate a network related failure or any kind of httpx exception, you can use add_exception and provide the exception to raise or add_callback and raise an exception as part of your callback.

4. Something else that I did not understand. In which case could you provide more details (a test scenario maybe)?

In the event that the information you are looking for is in one of the first 3 solutions above, could you please tell me what could be done to enhance the documentation so that it would be easier to find?

Best Regards

[ALSaleemALRaedah]

Hello @Colin-b,

While scenario two will solve my case I'm not satisfied with it as a technical solution. The solution should be simple and direct if an endpoint is called test fails. No exception raising required. I shouldn't need to change my business logic to accommodate unit test exception handling.

Best Regards

[Colin-b]

Hello @ALSaleemALRaedah ,

If you mocked one request on one URL but when your code is issuing 2 different requests you want it to fail, this is already the default behavior, as stated.
The only reason the test would succeed is if your code is considering an HTTP failure as "ok" behavior.
In such a case you would have to check the issued requests.

I agree with your approach, you shouldn't need to. However we might have users relying on the fact that the default response if no mock is found, is an HTTP Timeout.

This would be a breaking change, but one I might be willing to make. A minimal impact change would be a flag to enable/disable this behavior. And explicit is always better imo.

tl;dr:

One technical solution would be to introduce a new flag:

• Active:
  • unexpected calls will timeout (after waiting for real timeout or not is another thing to investigate here)
  • Test would fail at teardown if unexpected calls were made
• Inactive (revert to behavior at the time of this issue):
  • Unexpected calls will instantly timeout (again, should we wait for the real timeout ?)
  • Test would not fail at teardown if unexpected calls were made.

Would this solve your issue?

[ALSaleemALRaedah]

@Colin-b yeah this would solve my problem.