-
Notifications
You must be signed in to change notification settings - Fork 3
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
Support the use of a Session
object
#14
Conversation
…re meaningful Session testing
@@ -12,6 +12,7 @@ | |||
DEFAULT_POLLING_INTERVAL = 2 # in seconds | |||
DEFAULT_MAX_RETRIES = 50 | |||
VALID_CONDITIONS = ['status_code', 'json', 'jsonpath', 'text', 'callback'] | |||
DEFAULT_SESSION = requests.Session() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since our PreparedRequest
now comes from self.session.prepare_request(self.request)
instead of self.request.prepare()
- see below - there is a behavioural change in the default case (no Session
explicitly provided).
- From the links above, you can see that this involves merging in
Session
default headers, cookies, params, auth, and hooks. Of these,params
andauth
default to empty / none; I think the only interesting possibilities are aroundcookies
andheaders
. - If we consider the behavioural change acceptable, then we're good. If on the other hand we want to ensure no behavioural change, we can change the definition of
DEFAULT_SESSION
to override cookies and headers to empty dictionaries. Your call. - Additionally (Python style question) should
DEFAULT_SESSION
be a method rather than an instance variable? I worry that the lack of immutability means that somebody could accidentally changeDEFAULT_SESSION
and unintentionally affect other uses of it.
2 similar comments
args, kwargs = mock_adapter_send.call_args | ||
assert args[0].headers == {'Content-Type': 'test/type', 'Cookie': 'tasty-cookie=chocolate'} | ||
assert 'verify' in kwargs | ||
assert kwargs['verify'] == '/session/verify' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Initially, this test continued to fail even after I'd implemented the functionality.
The test case is where the session includes a specific value for verify
, but the user doesn't directly specify a value in the HttSleeper
API. Unfortunately, the session value was being ignored, and verify=True
was being used instead, running counter to the standard behaviour of the requests
library.
Thus I was forced to revisit the discussion we had in #12 (comment) about whether HttSleeper
should by default send verify=True
or leave the kwarg unspecified. That's why my 4th commit changes this behaviour back to that which I originally proposed in the last PR 😃
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aha, ok! Sorry for the back-and-forth, but at least the end result sounds perfect.
Hi @kopf, any chance of a review of this one when you have the chance? Many thanks. |
yup, it's on my todo list, extremely stressful time at work at the moment, will have a look at the weekend |
No worries! |
session = requests.Session() | ||
session.cookies = {'tasty-cookie': 'chocolate'} | ||
session.headers = {'Content-Type': 'test/type'} | ||
session.verify = '/session/verify' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be a boolean, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can be either a boolean or a string also - see https://github.com/requests/requests/blob/master/requests/api.py#L39-L41.
I thought it was worth having at least one or two non-boolean cases in the tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aha! I wasn't aware. OK, it's grand so
httsleep.run() | ||
assert mock_adapter_send.called | ||
args, kwargs = mock_adapter_send.call_args | ||
assert args[0].headers == {'conflict-header': 'req-wins', 'req-header': 'myRequest', 'session-header': 'mySession'} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool!
def test_request_verify_overrules_session_verify(): | ||
"""Should give precedence to the 'verify' setting in the request, over that in a specified Session""" | ||
session = requests.Session() | ||
session.verify = '/path/to/ca/bundle' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we not set this to True
and then do
httsleep = HttSleeper(URL, {'status_code': 200}, session=session, verify=False)
And then check whether verify
is False
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would of course work, but:
- as per my other comment,
verify
can be a string as well - I thought it improved readability of the test to have the overriding value of
/override/path
.
I can change it to a boolean case if you'd prefer, just say the word.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, grand, leave it as it is
Great stuff! All that's missing is a changelog entry. |
And you need to update the documentation - the "Polling" section of |
@kopf tutorial & changelog entries now added, please let me know if they need tweaking at all. |
LGTM, thanks again! |
Closes #13.
A couple of things are worth highlighting up-front - I'll comment on these inline.