I have looked at this infrastructural changes, and they are definitely low risk in my opinion. They're hugely beneficial also - because of parallel testing and replacing addCleanup with tearDown. I believe also Monty found some anti-patterns in test modules, and fixed them.
So, my vote is for switching to testtools + testr for the Grizzly release. Salvatore On 22 February 2013 15:02, Dan Wendlandt <[email protected]> wrote: > adding monty back in so he can comment. > > If we can get the changes in in the next few days, we consider them low > risk, and it gets us to the point that we can run parallel unit tests, to me > it makes sense in grizzly. > > Given that we run unit tests across all plugins, and the number of plugins > has grown significantly in G-3, the value of parallel test running is huge > for Quantum. > > Dan > > > > On Fri, Feb 22, 2013 at 5:49 AM, Gary Kotton <[email protected]> wrote: >> >> Are we able to go ahead and approve these patches. I was not sure if we >> wanted these for G release? >> Thanks >> Gary >> >> >> On 02/22/2013 02:38 AM, Dan Wendlandt wrote: >> >> Hi folks. Please see email below from Monty. >> >> First off, great work on writing so many tests :) >> >> Second, please start enforcing Mony's requirements around setUp/tearDown >> as we review code moving forward. >> >> dan >> >> ---------- Forwarded message ---------- >> From: Monty Taylor <[email protected]> >> Date: Wed, Feb 20, 2013 at 9:16 PM >> Subject: [openstack-dev] [quantum] unittest updates >> To: OpenStack Development Mailing List <[email protected]> >> >> >> Hey all! >> >> I'm working through Quantum patches to migrate unittests to testtools as >> step one in getting the testr parallel test running in place. >> Unfortunately for me, you are all WAY to productive and write more tests >> than I can keep up with the conversion of. :) >> >> To that end, I'd like to ask if folks could start doing the following to >> help: >> >> - If you add new tests and as part of doing that you add a setUp or a >> tearDown method - PLEASE add an upcall. This is going to be enforced by >> testtools soon anyway, so it's good to get in the habit >> >> - If you aren't overriding things in those methods, don't add them. For >> instance: >> >> def tearDown(self): >> pass >> >> is a bad idea - just leave it out >> >> (also - thanks for being so great about writing tests - it's an awesome >> problem to have) >> >> Monty >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> -- >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> Dan Wendlandt >> Nicira, Inc: www.nicira.com >> twitter: danwendlandt >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> >> >> >> -- >> Mailing list: https://launchpad.net/~quantum-core >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~quantum-core >> More help : https://help.launchpad.net/ListHelp >> > > > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Dan Wendlandt > Nicira, Inc: www.nicira.com > twitter: danwendlandt > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > -- > Mailing list: https://launchpad.net/~quantum-core > Post to : [email protected] > Unsubscribe : https://launchpad.net/~quantum-core > More help : https://help.launchpad.net/ListHelp > -- Mailing list: https://launchpad.net/~quantum-core Post to : [email protected] Unsubscribe : https://launchpad.net/~quantum-core More help : https://help.launchpad.net/ListHelp
