[openstack-dev] [all] [tests] Considering mock alternatives?

Robert Collins robertc at robertcollins.net
Fri Jul 10 12:00:30 UTC 2015


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'.

>>> from mock import Mock
>>> m = Mock(side_effect=KeyError('foo'))
>>> m()
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
https://github.com/testing-cabal/mock/issues/264

>>
>>> 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
>>> corner
>>> 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.

-Rob


-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud



More information about the OpenStack-dev mailing list