[openstack-dev] [Neutron][Testr] Brand new checkout of Neutron... getting insane unit test run results

Jay Pipes jaypipes at gmail.com
Mon Jan 13 23:44:19 UTC 2014

On Mon, 2014-01-13 at 22:16 +0000, Mark McClain wrote:
> I’d rather us explicitly skip the tests if the module is not available.

I think the danger with that is that you'll have developers running a
bunch of tests, getting skipped results (not failures), and thinking
that everything is hunky-dory -- until they then get a bunch of failures
in the gate and wonder why everything works fine for them but is
breaking in the gate.

After looking at Sean's patch, I think it's an acceptable solution. It's
not ideal, but that's only because Neutron's (and Nova's) unit tests are
not really unit tests at all. They're functional tests that test
significantly more than a single unit of code in each test method.

If the boundary tested in each test method were smaller and contained
only to a single unit of code, not dozens of function calls at once,
then it might be possible to simply mock.patch() the pyudev interface
intersections instead of come up with a no-op Fake implementation of


> On Jan 13, 2014, at 3:39 PM, Collins, Sean <Sean_Collins2 at cable.comcast.com> wrote:
> > On Wed, Jan 01, 2014 at 07:56:22PM -0800, Clark Boylan wrote:
> >> It looks like the problem is that there is a dependency on pyudev
> >> which only works properly on Linux. The neutron setup_hook does
> >> properly install pyudev on Linux (explains why the tests run in the
> >> gate), but would not work properly on windows or OS X. I assume folks
> >> are trying to run the tests on not Linux? Neutron may want to do
> >> something similar to what Nova does when libvirt is not importable,
> >> https://git.openstack.org/cgit/openstack/nova/tree/nova/tests/virt/libvirt/test_libvirt.py#n77
> >> and use a fake in order to get the tests to run properly anyways.
> > 
> > Thanks for pointing this out - I've begun work on doing this, and that
> > link was very helpful for figuring out what would need to be done.
> > 
> > -- 
> > Sean M. Collins
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> _______________________________________________
> 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