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

Ben Nemec openstack at nemebean.com
Fri Dec 6 16:55:42 UTC 2013


On 2013-12-05 21:38, Jay Pipes 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.

My understanding is that mox3 is a drop-in, Python 3 compatible version 
of mox.

I agree that spending any significant time maintaining mox3 is a bad 
thing at this point.  Mock is part of the stdlib in Python 3 and I don't 
think we should put a lot of time into reinventing the wheel.  That 
said, as long as mox3 works right now I don't think we should be 
rewriting mox test cases just to move them to mock either.  That's a 
whole lot of code churn for basically no benefit.

So my preference would be to:
1) Use mock for new test cases, with possible exceptions for adding to 
test classes that already use mox
2) Leave the existing mox test cases alone as long as they work fine 
with mox3.
3) If any test cases don't work in mox3, rewrite them in mock

-Ben



More information about the OpenStack-dev mailing list