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

Raise error if any version of patch is used as a context manager #168

Merged
merged 2 commits into from Nov 18, 2019

Conversation

AlexGascon
Copy link
Contributor

On #165, a change was added to raise an Exception when trying to use mocker.patch.object as a context manager, as its behavior is not supported in the plugin. However, the context managers for the remaining patch options (dict, multiple, and normal patch) still work as usual.

With this change, we check if we are in a context manager when starting the patch, so all the methods will raise the exception when corresponds.

On pytest-dev#165, a change was
added to raise an Exception when trying to use `mocker.patch.object` as
a context manager, as its behavior is not supported in the plugin.
However, the context managers for the remaining patch options (dict,
multiple, and normal patch) still work as usual.

With this change, we check if we are in a context manager when starting
the patch, so all the methods will raise the exception if corresponds
Adding a new test to confirm that patch raises an exception when used
as a context manager
@nicoddemus
Copy link
Member

Thanks @AlexGascon, just to let you know I will review this ASAP. 👍

Copy link
Member

@nicoddemus nicoddemus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot @AlexGascon!

@nicoddemus nicoddemus merged commit 845876e into pytest-dev:master Nov 18, 2019
@mcallaghan-bsm
Copy link

It would have been nice that this was a WARNING only, rather than a flat out ERROR. Certainly important to cleanup this unsupported usage, but this PR & release subsequently cause breakage in otherwise unchanged code if using the latest version of pytest-mock.

@nicoddemus
Copy link
Member

Hi @mcallaghan-bsm,

Thanks for the feedback, but I kindly disagree: the previous usage was causing false-positives, it is better to loudly complain about it IMHO. Users unfortunately many times ignore warnings.

@mcallaghan-bsm
Copy link

Yes that is fair. Just saying this impacts MANY users, forces them to clean up immediately rather than at their convenience. We've already cleaned up our poor usages :) for the better.

@AlexGascon
Copy link
Contributor Author

AlexGascon commented Nov 19, 2019

As a user myself I agree with @nicoddemus, I would definitely prefer getting an exception and knowing that what I am trying is not supported than introducing it in my codebase and not realizing the problem.

Besides, it's not as if we were talking about a feature that suddenly stopped working, but about something that never worked and now is just notifying you about it. If I was using it on my tests I would definitely appreciate knowing that I'm doing something that doesn't work at all

@nicoddemus
Copy link
Member

We've already cleaned up our poor usages :) for the better.

Good to hear. 😁

Yes that is fair. Just saying this impacts MANY users, forces them to clean up immediately rather than at their convenience.

That's true, but the alternative would be to eventually turn the warning into an error, and then users who have been ignoring the warning would get the error anyway. Also users can always postpone the cleanup by pinning to <1.12 in their requirements.

FTR in general I completely agree with you that introducing warnings to, well, warn about incoming changes/incompatibilities is the way to go, but in this case it was something that was really not working at all, so I think for those cases it makes sense to turn it into an error immediately. 😁

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

Successfully merging this pull request may close these issues.

None yet

3 participants