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

[Gregory P. Smith]

On Sat, Oct 2, 2010 at 3:24 PM, Michael Foord <fuzzyman at voidspace.org.uk>wrote:

>  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:
>

Hmm, I am more comfortable with that approach.

I agree that dependency injection altering the public API is bad. For
example I wouldn't do it for public APIs on the standard library.

But buried within a code base in a project where it isn't exposed to outside
users I don't mind so much.  There are also other dep. injection styles such
as adding private attributes or methods to your class for the things you
want to inject at test time rather than my simple example of a _ prefixed
"protected by convention" additional parameter.  Adding your own mock open
to the module global namespace is doing something similar but happily
doesn't need code modifications to support the injection.

-gps


> 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.
>
>
> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20101002/d8039f95/attachment-0001.htm>