[openstack-dev] Usage of mox through out the Openstack project.

Brian Curtin brian.curtin at RACKSPACE.COM
Wed Jul 24 18:41:53 UTC 2013

On Jul 24, 2013, at 1:12 PM, Chuck Short <chuck.short at canonical.com<mailto:chuck.short at canonical.com>>


The use of mox (https://pypi.python.org/pypi/mox/0.5.3) across the test suites in the Openstack project is quite extensive. This is probably due to the fact that it is the most familiar mocking object framework for most python developers.

However there is big drawback with using mox across all of the OpenStack projects is that it is not python3 compatible. This makes python3 compliance problematic because we want the test suites to be compatible as well.

While thinking about this problem for a while now, while helping porting OpenStack over to python3 there is a couple of options that as a project can do as a whole:

1. Change mox usage to more python3 friendly such as mock. (https://pypi.python.org/pypi/mock/1.0.1). However this will cause alot of code churn in the projects as we move away from mox to mock.

2. Use the python3 fork called pymox (https://github.com/emonty/pymox). This project has reasonable compatibility with mox and is python3 compatible. Using this option causes less code churn. IMHO this would be the better option.

I would like to hear peoples opinion on this.

Moving towards the standard library's unittest.mock for 3 and the external package for 2 is what I've done in the past, but I moved away from mocker and another one I forget, not mox.

Are there usages of mox that aren't served by mock? Code churn sucks, but if something has to change, I think there's value in moving toward the standard facilities if they'll do the job.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130724/23cba3a2/attachment.html>

More information about the OpenStack-dev mailing list