Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add param to disable verify over non-requested mock. #76

Closed
wants to merge 2 commits into from

Conversation

Bernardoow
Copy link

I had a scenario where I wanted to all request to be verified about over non-request, but just ONE request I wanted to be free verification.

With this new feature I can achieve this logic.

@sonarcloud
Copy link

sonarcloud bot commented May 7, 2022

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
No Duplication information No Duplication information

@Bernardoow Bernardoow changed the title Add param to disable unrequested mock. Add param to disable verify over non-requested mock. May 7, 2022
@Colin-b
Copy link
Owner

Colin-b commented May 9, 2022

Thanks for the proposal @Bernardoow , could you please give more details on the test case itself and why you would need to mock something that is not called by your code ?

@Bernardoow
Copy link
Author

Bernardoow commented May 16, 2022

Hi @Colin-b,

I usually use a parametrize. So, I put two codes that one call and another not.

I put this option to allow developers to choose the away to check about the called. I tried to 'override' the fixture inside of the test but it not worked.

In another tests I want the behavior that raise exception when the mock isnot called.

@citrusLover
Copy link

Hi @Bernardoow, I had a similar need.
What I ended up doing was at the end of my test manually call httpx_mock.reset(False) for the test in which I didn't want to the assert_all_responses_were_requested-check to be active.

I think this also solves your case in which for some tests you want the assert and in other tests you don't. And you can also parameterise that.

@artofhuman
Copy link

@Colin-b Hi, Do you have plans to merge this PR? In my case, we use lru_cache for one request, which we do when our app started. In tests, we have error because we have cache across tests.

@Colin-b
Copy link
Owner

Colin-b commented Sep 5, 2023

I don't think we'll move forward with this implementation proposal. However I acknowledge the need to be able to have the assert_all_responses_were_requested parameter changing from one test case to another.

Right now, you could achieve this by using a separate file with a different fixture value in each file. Or you could even do as proposed by @citrusLover with the downside being that if your test case fail before reaching the call to reset, you will not be in a state that you want.

A cleaner solution would be to have a marker that you could set on the test case itself allowing to set assert_all_responses_were_requested. Would that solve your use case @Bernardoow or do you meant that you want to be able to change the value in a single parametrize test case (meaning you have one boolean parameter setting it to True for one run and False for another) ?

@artofhuman I don't think your concern is related to this pull request, unless I am mistaken you want your cache to be cleared in between test cases. That is not a problematic linked to pytest-httpx, but rather the way you setup your cache to be reset from one test to another. You would have the same issue if you were using real queries in your test suite no?

@Colin-b
Copy link
Owner

Colin-b commented Feb 20, 2024

As I have no responses on this, I'll close it. A new issue (#137) was opened to introduce decorators instead of fixtures to address your need of different httpx settings in the same test file. Because if you are already using different test files, you can already set this up using fixtures.

@Colin-b Colin-b closed this Feb 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants