[TIP] Is this the best way to mock out a call to with open('foo') as f?

Michael Foord fuzzyman at voidspace.org.uk
Sat Oct 2 15:24:13 PDT 2010


  On 02/10/2010 21:34, W. Matthew Wilson wrote:
> I'm using the mock package version 7.  Here's the production code I
> want to test:
>
>      def to_html(self, filepath):
>          """
>          Write this bag out as HTML to a file at filepath.
>          """
>
>          with open(os.path.join(filepath, self.html_filename), 'w') as f:
>              f.write(self.html)
>
> And here's the test for that to_html method.  I'm using mock.patch to
> substitute a MagicMock object in for the results of the call to
> open(...).
>
>      @mock.patch(
>          '__builtin__.open',
>          mock.Mock(return_value=mock.MagicMock(spec=file)))
>      def test_to_html():
>
>          global b
>          b.to_html('bogus filepath')
>
> It took me a long time to figure out how to do this.  And that makes
> me think maybe there's a much simpler and cleaner approach out there.
>
In principle I think that the way you patch __builtin__.open with a mock 
that returns a MagicMock is fine. To answer Gregory's particular 
nervousness about patching __builtin__ - the use of "patch" makes 
guarantees about when the patching will be done and undone so it won't 
affect any code run outside of the specific test.

However, there is an alternative way. You could *just* patch the 'open' 
function in the module under test. Because 'open' won't exist in that 
namespace as an explicit name you will have to use the create keyword 
argument to patch:

with patch('the_module.open', Mock(return_value=MagicMock(spec=file)), 
create=True):
...

or even:

@patch('module.open', create=True)
def the_test(mock_open):
mock_open.return_value = MagicMock(spec=file)

All the best,

Michael Foord


> My example is different than the one in the documentation
> (http://www.voidspace.org.uk/python/mock/magicmock.html) because that
> one looks like this:
>
>>>> from mock import Mock
>>>> mock = Mock()
>>>> mock.__enter__ = Mock()
>>>> mock.__exit__ = Mock()
>>>> mock.__exit__.return_value = False
>>>> with mock:
> ...     pass
>
> In that one, mock needs to support calls to __enter__ and __exit__.
>
> where this one is mine:
>
>      with open(...) as f:
>
> In mine, the open function needs to return something that can support
> calls to __enter__ and __exit__.
>
> So, that's why I'm making a regular mock.Mock object that then returns
> a fancy mock.MagicMock(spec=file) object.
>
> Like I said, it took me a long time to figure this out, and I find it
> confusing to read, so I hope there's some more elegant solution out
> there.
>
> Great library, by the way.
> Matt
>
>


-- 
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree,
on behalf of your employer, to release me from all obligations
and waivers arising from any and all NON-NEGOTIATED agreements,
licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap,
confidentiality, non-disclosure, non-compete and acceptable use
policies (”BOGUS AGREEMENTS”) that I have entered into with your
employer, its partners, licensors, agents and assigns, in
perpetuity, without prejudice to my ongoing rights and privileges.
You further represent that you have the authority to release me
from any BOGUS AGREEMENTS on behalf of your employer.




More information about the testing-in-python mailing list