[TIP] Is this the best way to mock out a call to with open('foo') as f?
fuzzyman at voidspace.org.uk
Tue Oct 5 03:30:20 PDT 2010
On 03/10/2010 01:48, Gregory P. Smith wrote:
> On Sat, Oct 2, 2010 at 3:24 PM, Michael Foord
> <fuzzyman at voidspace.org.uk <mailto: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:
> 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
> 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
> me think maybe there's a much simpler and cleaner approach out
> 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 even internal APIs still need to be read / used by developers and I
don't like screwing with them either.
> 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.
Right. My contention is that dependency injection *just* for testability
is never *required* for Python and rarely preferable to other
techniques. There are plenty of times when dependency injection is
useful as a structure / architecture in its own right though.
All the best,
> 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
> 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
> where this one is mine:
> with open(...) as f:
> In mine, the open function needs to return something that can
> calls to __enter__ and __exit__.
> So, that's why I'm making a regular mock.Mock object that then
> 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
> Great library, by the way.
> 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
> <mailto:testing-in-python at lists.idyll.org>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the testing-in-python