python / cpython

The Python programming language
https://www.python.org
Other
63.69k stars 30.51k forks source link

Replacement for unittest.mock.mock_open #69876

Open b353cb94-29a0-46e2-998d-74ccc217d63c opened 9 years ago

b353cb94-29a0-46e2-998d-74ccc217d63c commented 9 years ago
BPO 25690
Nosy @rbtcollins, @ezio-melotti, @bitdancer, @voidspace
Files
  • mock_open.patch
  • mock_open.patch
  • mock_open.patch
  • 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: ```python assignee = None closed_at = None created_at = labels = ['tests', 'type-feature', 'library'] title = 'Replacement for unittest.mock.mock_open' updated_at = user = 'https://bugs.python.org/NivBen-David' ``` bugs.python.org fields: ```python activity = actor = 'Niv Ben-David' assignee = 'none' closed = False closed_date = None closer = None components = ['Library (Lib)', 'Tests'] creation = creator = 'Niv Ben-David' dependencies = [] files = ['41113', '41762', '42175'] hgrepos = [] issue_num = 25690 keywords = ['patch'] message_count = 5.0 messages = ['255061', '255078', '259268', '261714', '261825'] nosy_count = 5.0 nosy_names = ['rbcollins', 'ezio.melotti', 'r.david.murray', 'michael.foord', 'Niv Ben-David'] pr_nums = [] priority = 'normal' resolution = None stage = 'patch review' status = 'open' superseder = None type = 'enhancement' url = 'https://bugs.python.org/issue25690' versions = ['Python 3.6'] ```

    b353cb94-29a0-46e2-998d-74ccc217d63c commented 9 years ago

    The unittest.mock module defines a mock_open utility to mock the builtin open function.

    During a recent project I found I needed something more. Specifically, mocking different files at the same time, better mocking for operations (like seek, readlines, etc.) among others.

    The project can also be found on http://github.com/nivbend/mock-open

    Thanks

    bitdancer commented 9 years ago

    Thanks for the submission. I haven't looked at this in detail, but the fact that you are changing existing unit tests indicates there is probably a backward compatibility problem with your patch. Also if you are adding features I'd expect there to be doc changes, which would make it easier to understand what you are proposing.

    b353cb94-29a0-46e2-998d-74ccc217d63c commented 8 years ago

    Regarding the documentation changes, my version simply mocks open more "closely", so for the most part I can't think of any changes to the documentation. I've added a bit about the mock object acting as a map of file names to mock objects. Should I add anything else?

    Regarding the tests, I've tried changing as little as possible to make sure I don't have any backward compatibility issues. However, some changes had to be made:

    Sorry about the (very) late response, I've been preoccupied lately.

    rbtcollins commented 8 years ago

    Hmm, I haven't looked closely, but some high level thoughts.

    I'm worried about making mock too complex here. We already say folk should use a VFS for complex file based tests, and there's quite a chunk of code you're adding - perhaps better to just use a VFS?

    I don't like mock importing mock_open and mock_open importing mock: please keep this in a single mock.py at this point.

    b353cb94-29a0-46e2-998d-74ccc217d63c commented 8 years ago

    I copied the code in place of the old mock_open in unittest/mock.py.

    Regarding the VFS issue, I think that it really depends on what you're trying to test. If you only care about "side effects" on the file system, the VFS way it much better and easier. But if you want to test the way files are handled by your code (proper handling of errors during open/read/write seems the obvious thing here, but I can think of other use cases), then I think MockOpen is the better tool.