[Python-ideas] SealedMock proposal for unittest.mock

Mario Corchero mariocj89 at gmail.com
Thu Jun 1 08:43:44 EDT 2017


Having it part of the existing Mock class might be great. I really like the
idea of mock.seal(mock_object).
Let me try it out and draft some code and I'll open the issue. Thanks :)

On 1 June 2017 at 13:29, Julien Duponchelle <julien at gns3.net> wrote:

> Perhaps you can set via configure_mock. This will prevent conflict with
> existing code.
>
> Julien
>
> On Thu, Jun 1, 2017 at 2:17 PM Victor Stinner <victor.stinner at gmail.com>
> wrote:
>
>> A stricter mock object cannot be a bad idea :-) I am not sure about your
>> proposed API: some random code may already use this attribute. Maybe it can
>> be a seal (mock) function which sets a secret attribute with a less common
>> name?
>>
>> Yeah, please open an issue on bugs.python.org ;-)
>>
>> Victor
>>
>>
>> Le 29 mai 2017 11:33 PM, "Mario Corchero" <mariocj89 at gmail.com> a écrit :
>>
>>> Hello Everyone!
>>>
>>> First time writing to python-ideas.
>>>
>>> *Overview*
>>> Add a new mock class within the mock module
>>> <https://github.com/python/cpython/blob/master/Lib/unittest/mock.py>,
>>> SealedMock (or RestrictedMock) that allows to restrict in a dynamic and
>>> recursive way the addition of attributes to it. The new class just defines
>>> a special attribute "sealed" which once set to True the behaviour of
>>> automatically creating mocks is blocked, as well as for all its "submocks".
>>> See sealedmock
>>> <https://github.com/mariocj89/sealedmock/blob/master/README.md>. Don't
>>> focus on the implementation, it is ugly, it would be much simpler within
>>> *mock.py*.
>>>
>>> *Rationale*
>>> Inspired by GMock
>>> <https://github.com/google/googletest/tree/master/googlemock> RestrictedMock,
>>> SealedMock aims to allow the developer to define a narrow interface to the
>>> mock that defines what the mocks allows to be called on.
>>> The feature of mocks returning mocks by default is extremely useful but
>>> not always desired. Quite often you rely on it only at the time you are
>>> writing the test but you want it to be disabled at the time the mock is
>>> passed into your code, that is what SealedMock aims to address.
>>>
>>> This solution also prevents user errors when mocking incorrect paths or
>>> having typos when calling attributes/methods of the mock.
>>> We have tried it internally in our company and it gives quite a nicer
>>> user experience for many use cases, specially for new users of mock as it
>>> helps out when you mock the wrong path.
>>>
>>> *Alternatives*
>>>
>>>    - Using auto_spec/spec is a possible solution but removes
>>>    flexibility and is rather painful to write for each of the mocks and
>>>    submocks being used.
>>>    - Leaving it outside of the mock.py as it is not interesting enough.
>>>    I am fine with it :) just proposing it in case you think otherwise.
>>>    - Make it part of the standard Mock base class. Works for me, but
>>>    I'd concerned on how can we do it in a backward compatible way. (Say
>>>    someone is mocking something that has a "sealed" attribute already).
>>>
>>> Let me know what you think, happy to open a enhancement in
>>> https://bugs.python.org/ and send a PR.
>>>
>>> Regards,
>>> Mario
>>>
>>> _______________________________________________
>>> Python-ideas mailing list
>>> Python-ideas at python.org
>>> https://mail.python.org/mailman/listinfo/python-ideas
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20170601/3de2d899/attachment.html>


More information about the Python-ideas mailing list