[openstack-dev] [all] [tests] Considering mock alternatives?
dtantsur at redhat.com
Fri Jul 10 12:08:41 UTC 2015
On 07/10/2015 02:00 PM, Robert Collins wrote:
> On 10 July 2015 at 23:34, Dmitry Tantsur <dtantsur at redhat.com> wrote:
>> On 07/10/2015 01:13 PM, Robert Collins wrote:
>> I see that a lot of code started breaking due to
>> side_effect = Exception()
>> no longer working. Which was a declared way for some time, at least to my
>> best knowledge. And I do realize it's just a back port, but as a user of a
>> _library_ I'd like such breakages to be treated with care.
>> Maybe it happened and I was just not looking at a proper place.
> Well, it works in the test suite, and it works by hand for me. So its
> not as simple as 'oh look someone didn't care'.
Yeah, sorry. I'm happy to hear that it was not intentional.
>>>> from mock import Mock
>>>> m = Mock(side_effect=KeyError('foo'))
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> File "mock/mock.py", line 1055, in __call__
> return _mock_self._mock_call(*args, **kwargs)
> File "mock/mock.py", line 1111, in _mock_call
> raise effect
> KeyError: 'foo'
> I accept that this is affecting Openstack, it sounds like the same
> thing affecting Neutron and Nova, which turned out to be a bug in
> autospec: try changing from 'autospec=True' to 'spec=True' [the nova
> code didn't use set_spec=True, you may want/need to turn that off as
> well]. Please capture any learnings to
spec=True is not a complete replacement (does not seem to check method
signature) and is not documented to be used this way (well, at least I
didn't find it). But yeah, it kind of works.
>>>> 2. side_effect syntax is no longer sane. Previously it was awesome:
>>>> side_effect = Exception()
>>>> side_effect = [value, Exception()]
>>>> etc. Now it's a big typing disaster:
>>>> side_effect = iter([Exception()])
>>>> ok, I can live with , I understand that it may be required for some
>>>> cases. I can't understand why mock can't call iter() internally.
>>>> And seriously, it's a breaking change, and should have been
>>>> communicated/issued a warning for some time.
>>> It doesn't show up in the test suite - and I put specific code in
>>> place to deal with the potentially related case where Python 2.7's
>>> next() is different to the 3.x next() [2.6 didn't have next()]. So -
>>> if you've found something that works in unittest.most on Python 3.6
>>> [or 3.5beta3] then its a genuine backport bug and I can fix that up
>>> asap. I haven't seen a bug filed from you about it, so perhaps thats
>>> the first step.
>> People say it's stopped working in Python 3.4.2 and it did work in Python
>> 3.4.0. I didn't verify this sentence.
> So, if its stopped working in cPython, then we're going to want to
> follow that (and bugfixes should go straight into cPython too). Once
> its in 3.6 we can backport it very rapidly.
More information about the OpenStack-dev