-
-
Notifications
You must be signed in to change notification settings - Fork 196
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
Comments
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:
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? |
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? |
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:
tavern/tavern/_plugins/rest/request.py
Line 457 in c1f9da8
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
The text was updated successfully, but these errors were encountered: