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
Add mock_import method to mock module #71563
Comments
Add mock_import method. A helper function to mask The do_not_mock argument is a package or module name, or package or module names list. When specified, and imported in the scoped mocked code, importing them must succeed. If |
Is this for mocking out runtime dependencies that aren't available at test time? It seems like a good way of masking bugs! I'd be happier with a (or at least an option) to specify the imports that should be mocked. The use case should be mentioned in the docs. I think the name is slightly confusing. I originally thought this was a function to mock specific imports - not to catch failed imports. mock_missing_import (or similar) would be a better name. It's common with the mock functions to be able to provide a class to use as the mock function, and to take arbitrary keyword arguments to pass to the mock constructor. |
Thanks for the review, Michael. About the use case: I use it for a process with loads code and inspect it's classes and methods. When I run this process, not always I have all the dependencies of the inspected code, so I found myself mocking all those packages before running the inspection code. This was very inconvenience, and broke any time someone added a new dependency to the code which is not in the standard library. About the name: I agree. About the keyword for the mock constructor: no problems. Should I fix the code and submit an updated patch? |
It's not a use case I've specifically had but I can see its use. I'm uncertain of whether that means it belongs in the module or not. Let me see if I can get some more eyes on this bug. |
Before you spend any more time on this, my current thinking is that this is a bit too specialised to belong in the standard library. I'll wait and see if a preponderance of core devs and other users disagree with me before I close this though. |
Some real use cases is needed, like testing a code that behave differently on case of package availability. I think something like patch for modules can be useful here, so you could have some control on what would be returned. |
Closing as that's where the discussion of 2016 was leaning. Please raise this on python-ideas if you would like to bring it up again. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: