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 <[email protected]> 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 <[email protected]> > 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" <[email protected]> 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 >>> [email protected] >>> https://mail.python.org/mailman/listinfo/python-ideas >>> Code of Conduct: http://python.org/psf/codeofconduct/ >>> >>> _______________________________________________ >> Python-ideas mailing list >> [email protected] >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> >
_______________________________________________ Python-ideas mailing list [email protected] https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
