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

How to parametrize the proxy used by the underlying request call? #673

Open
gc-ss opened this issue Apr 17, 2021 · 4 comments
Open

How to parametrize the proxy used by the underlying request call? #673

gc-ss opened this issue Apr 17, 2021 · 4 comments

Comments

@gc-ss
Copy link

gc-ss commented Apr 17, 2021

Assume I am testing an endpoint that returns the current timestamp and I have code that operates on that timestamp. This code is under test by tavern.

I would like to parametrize the same test to run twice - once against a cached/known timestamp and then live/unknown timestamp.

If the test that runs against the known timestamp passes but fails against the unknown timestamp, I can be sure there wasn't a regression in my code while I was refactoring my code.

The underlying requests call is prepared here:

return session.request(**self._request_args)

requests has a proxy option that can be passed in in the function call.

I would like to pass that proxy option as a parameter from tavern test so that I can run the same test through multiple proxy settings.

Here's a more detailed description of a usecase of service virtualization that requires this kind of parametrization: wrike/pytest-hoverfly#3 (comment)

I see a related issue that exists but that was closed by the OP #530

I also left a comment on another related issue where this usecase of service virtualization wasn't clear: #103

@michaelboulton
Copy link
Member

This isn't supported at the moment (Tavern tries to focus more on the application layer than anything below that) but it might not be too difficult to add.

@gc-ss
Copy link
Author

gc-ss commented Apr 18, 2021

This isn't supported at the moment (Tavern tries to focus more on the application layer than anything below that) but it might not be too difficult to add.

Thank you Michael, I appreciate it.

From my POV, I am thinking it's a matter of:

  1. adding proxies (https://docs.python-requests.org/en/latest/api/#requests.request) to _request_args:
  2. that makes proxies available in self._request_args:
    self._request_args = request_args
  3. … hence when session.request(**self._request_args) is run, proxies is made to available the request :
    return session.request(**self._request_args)

let me know what you think - is this the right approach?

If so, if I put up a PR with these changes, what additional steps would be needed for you to merge it in?

@michaelboulton
Copy link
Member

If you want to make a PR then go ahead, it does look fairly simple to fix.

@gc-ss
Copy link
Author

gc-ss commented May 3, 2021

If you want to make a PR then go ahead, it does look fairly simple to fix.

Will do. I have not made a PR to taverntesting before. Aside from ensuring the code I submit is PEP8 compliant, what are some other things to keep in mind?

Also, do you have some suggestions/references for me to look into or follow when writing tests for this update/change?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants