[openstack-dev] [nova] Do we have some guidelines for mock, stub, mox when writing unit test?

John Griffith john.griffith at solidfire.com
Mon Dec 23 17:09:15 UTC 2013


On Thu, Dec 5, 2013 at 8:38 PM, Jay Pipes <jaypipes at gmail.com> wrote:
> On 12/04/2013 12:10 PM, Russell Bryant wrote:
>>
>> On 12/04/2013 11:16 AM, Nikola Đipanov wrote:
>>>
>>> Resurrecting this thread because of an interesting review that came up
>>> yesterday [1].
>>>
>>> It seems that our lack of a firm decision on what to do with the mocking
>>> framework has left people confused. In hope to help - I'll give my view
>>> of where things are now and what we should do going forward, and
>>> hopefully we'll reach some consensus on this.
>>>
>>> Here's the breakdown:
>>>
>>> We should abandon mox:
>>> * It has not had a release in over 3 years [2] and a patch upstream for 2
>>> * There are bugs that are impacting the project with it (see above)
>>> * It will not be ported to python 3
>>>
>>> Proposed path forward options:
>>> 1) Port nova to mock now:
>>>    * Literally unmanageable - huge review overhead and regression risk
>>> for not so much gain (maybe) [1]
>>>
>>> 2) Opportunistically port nova (write new tests using mock, when fixing
>>> tests, move them to mock):
>>>   * Will take a really long time to move to mock, and is not really a
>>> solution since we are stuck with mock for an undetermined period of time
>>> - it's what we are doing now (kind of).
>>>
>>> 3) Same as 2) but move current codebase to mox3
>>>   * Buys us py3k compat, and fresher code
>>>   * Mox3 and mox have diverged and we would need to backport mox fixes
>>> onto the mox3 three and become de-facto active maintainers (as per Peter
>>> Feiner's last email - that may not be so easy).
>>>
>>> I think we should follow path 3) if we can, but we need to:
>>>
>>> 1) Figure out what is the deal with mox3 and decide if owning it will
>>> really be less trouble than porting nova. To be hones - I was unable to
>>> even find the code repo for it, only [3]. If anyone has more info -
>>> please weigh in. We'll also need volunteers
>>>
>>> 2) Make better testing guidelines when using mock, and maybe add some
>>> testing helpers (like we do already have for mox) that will make porting
>>> existing tests easier. mreidem already put this on this weeks nova
>>> meeting agenda - so that might be a good place to discuss all the issues
>>> mentioned here as well.
>>>
>>> We should really take a stronger stance on this soon IMHO, as this comes
>>> up with literally every commit.
>>
>>
>> I think option 3 makes the most sense here (pending anyone saying we
>> should run away screaming from mox3 for some reason).  It's actually
>> what I had been assuming since this thread a while back.
>
>
> What precisely is the benefit of moving the existing code to mox3 versus
> moving the existing code to mock? Is mox3 so similar to mox that the
> transition would be minimal?
>
>
>> This means that we don't need to *require* that tests get converted if
>> you're changing one.  It just gets you bonus imaginary internet points.
>>
>> Requiring mock for new tests seems fine.  We can grant exceptions in
>> specific cases if necessary.  In general, we should be using mock for
>> new tests.
>
>
> My vote would be to use mock for everything new (no brainer), keep old mox
> stuff around and slowly port it to mock. I see little value in bringing in
> another mox3 library, especially if we'd end up having to maintain it.

FWIW this is exactly what the Cinder team agreed upon a while back and
the direction we've been going.  There hasn't really been any
push-back on this and in most cases the response from people has been
"Wow, using mock was so much easier/straight forward".

>
> Best,
> -jay
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list