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
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@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@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
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@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@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@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
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@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@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@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@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
participants (3)
-
Julien Duponchelle -
Mario Corchero -
Victor Stinner