Request/response mocking for testing purposes
amotl opened this issue · comments
Ah, right. I am now using initialization code like this in pytest's conftest.py. It perfectly works around the problem.
import pytest
@pytest.fixture(scope="session", autouse=True)
def niquests_patch_all():
from sys import modules
import niquests
import urllib3
# Amalgamate the module namespace to make all modules aiming
# to use `requests`, in fact use `niquests` instead.
modules["requests"] = niquests
modules["requests.adapters"] = niquests.adapters
modules["requests.sessions"] = niquests.sessions
modules["requests.exceptions"] = niquests.exceptions
modules["requests.packages.urllib3"] = urllib3-- grafana-toolbox/grafana-wtf#130 (review)
Maybe the documentation can be improved, by providing corresponding guidance?
Hello,
Maybe you've missed it, but we did write about this https://niquests.readthedocs.io/en/latest/dev/migrate.html#maintainer-migration
regards,
Thank you very much for the reminder, I knew we had this on the radar just recently.
Apparently, I haven't been able to find it back, because the page lacks corresponding keywords, and response has a typo, should be called responses.
When iterating on the documentation next time, may I suggest to also add keywords like "patch" and/or "monkeypatch" to the Migration Guide documentation section?
I may be coming from a different school of thought, more thinking in terms of integration instead of migration. In this case, I approached the documentation in a way to find about about integration capabilities with the responses package.
In the same spirit, I think the page Recommended Packages and Extensions could also use the keyword "integration" somewhere on it, to make it easier to discover using documentation search, when using a different kind of jargon.
Personally, I would expect all those items to be presented on a single page. I guess I would finally have discovered it by using "pytest" as a search term, instead of complaining here right away. However, I thought that Niquests, being an excellent package already, also needs excellent documentation, even in those nit-picky areas, so I wanted to add my two cents, in order to convey our perspectives on how we approached the documentation.
In this case, corresponding improvements primarily should serve people like us, who are writing software tests on a daily basis, sometimes for libraries only rarely maintained. In such situations, any kinds of helper tools are always well appreciated, and, in this case, would make migration to Niquests easier, if it would transparently integrate with tests suites better, without actually changing any code.
As you can see, we are really strong proponents for adding this monkeypatching code snippet to the niquests package itself, so it becomes more re-usable for 3rd party applications, which use the niquests package directly, but also transitively.
If you are not comfortable adding this snippet the main module namespace, maybe you could consider adding it to niquests.testing, like how others are doing it, in order to support their downstream libraries and applications by providing corresponding testing helpers to them?
On the other hand, you already mentioned on another occasion that you are not comfortable adding this snippet to the code base. So, if we haven't been able to convince you up until now, we will surely stop bothering you about it ;].
maybe you could consider adding it to niquests.testing, like how others are doing it, in order to support their downstream libraries and applications by providing corresponding testing helpers to them?
I'll think about it. And propose a implementation that would suit all of us. Will keep you posted.
regards,
edit: trying to see how "responses" can help to avoid complex patching utilities see getsentry/responses#710
update: "responses" agreed to review a PR for Niquests optional support. I will propose a PR at my early.
update: unfortunately we did not get attention on our attempt to bring "responses" compatible with both Niquests and Requests.
It's probable that "responses" won't dedicate time to review any PR on that specific topic unless someone else "than me" would start the process.
In the meantime, two possibilities are offered to anyone stumbling in that issue:
- A) Install my patch directly via git
https://github.com/Ousret/responses/tree/support-niquests - B) Patch sys.module as presented in the docs https://niquests.readthedocs.io/en/latest/dev/migrate.html#maintainer-migration
As it is not an issue with Niquests, I am closing it.
Regards,