-
Notifications
You must be signed in to change notification settings - Fork 1
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
then_enter_with(None)
makes the stub return None
instead of an enterable context manager
#135
Comments
then_enter_with(None)
makes the not configure a context manager stubthen_enter_with(None)
makes the stub return None
instead of an enterable context manager
An easy workaround is to provide some arbitrary dummy value to |
Shoot, we need a sentinel for this to work. Stubbing a I think the better workaround here is to return a CM mock with its # don't do this
decoy.when(mock_dep.get_context()).then_enter_with("<dummy_value>")
# do this
mock_cm = decoy.mock()
decoy.when(mock_dep.get_context()).then_return(mock_cm)
# ...
# pretty sure this will work, will test it out though
decoy.verify(
mock_cm.__enter__(),
# ...
) |
If you have production code that looks like this:
Then its Decoy test might do:
But sometimes the
with
statement has noas
clause:I expected this to work:
But this causes the production code's call to
foo.bar(bar_arg)
to returnNone
. It should instead return a context manager that returnsNone
when it's entered.It looks to me like this is an unintentional side-effect of the way
StubBehavior
works internally:decoy/decoy/stub_store.py
Lines 7 to 14 in c23d145
It can't distinguish between being configured with a
context_value
that'sNone
versus not being configured with acontext_value
at all.To solve a similar problem, the implementation of
dataclasses
uses a specialMISSING
sentinel value that's distinct fromNone
. Maybe a similar pattern could work here.The text was updated successfully, but these errors were encountered: