On 30 Nov 2011 - 19:26, Chris Behrens wrote: > I need to catch up a bit with this thread, but I wanted to mention I > have a huge patch coming that refactors almost all of the scheduler > tests into true unit tests.
Nice! > I'd started this for other reasons and I > hope it jives with the plans here. But if anyone is looking at the > scheduler tests, we should sync up. I was going to actually use the scheduler as the example when I sent this email out, but I switched to something a bit cleaner instead... so this is great news! Can't wait to see it :-) d > - Chris > > On Nov 30, 2011, at 1:07 PM, Duncan McGreggor <dun...@dreamhost.com> wrote: > > > On Tue, Nov 29, 2011 at 12:21 PM, Soren Hansen <so...@linux2go.dk> wrote: > >> It's been a bit over a week since I started this thread. So far we've > >> agreed that running the test suite is too slow, mostly because there > >> are too many things in there that aren't unit tests. > >> > >> We've also discussed my fake db implementation at length. I think > >> we've generally agreed that it isn't completely insane, so that's > >> moving along nicely. > >> > >> Duncan has taken the first steps needed to split the test suite into > >> unit tests and everything else: > >> > >> https://review.openstack.org/#change,1879 > >> > >> Just one more core +1 needed. Will someone beat me to it? Only time > >> will tell :) Thanks, Duncan! > >> > >> Anything else around unit testing anyone wants to get into The Great > >> Big Plan[tm]? > > > > Actually, yeah... one more thing :-) > > > > Jay and I were chatting about organization of infrastructure last > > night/this morning (on the review comments for the branch I > > submitted). He said that I should raise a concern I expressed for > > wider discussion: right now, tests are all piled into the tests > > directory. Below are my thoughts on this. > > > > I think such an approach is just fine for smaller projects; there's > > not a lot there, and it's all pretty easy to find. For large projects, > > this seems like not such a good idea for the following reasons: > > > > * tests are kept separate from the code they relate to > > * there are often odd test module file naming practices required > > (e.g., nova/a/api.py and nova/b/api.py both needing test cases in > > nova/tests/) > > * there's no standard exercised for whether a subpackage gets a > > single test case module or whether it gets a test case subpackage > > * test modules tend to be very long (and thus hard to navigate) due > > to the awkwardness of naming modules when all the code lives together > > * it makes it harder for newcomers to find code; when they live > > together, it's a no-brainer > > > > OpenStack is definitely not a small project, and as our test coverage > > becomes more complete, these issues will have increased impact. I > > would like to clean all of this up :-) And I'm volunteering to do the > > work! Here's the sort of thing I envision, using nova.volume as an > > example: > > > > * create nova/volume/tests > > * move all scheduler-related tests (there are several) from > > nova/tests into nova/volume/tests > > * break out tests on a per-module basis (e.g., nova/volume/driver.py > > would get the test module nova/volume/tests/test_driver.py, etc.) > > * for modules that have already been broken out at a more > > fine-grained level, keep (smaller test case modules are nice!) > > * only nova/*.py files will have a test case module in nova/tests > > * bonus: update the test runner to print the full dotted path so it's > > immediately (and visually) clear where one has to go to address any > > failures > > > > Given approval, this work would be done in its own blueprint. All this > > work would be done in small chunks (probably one branch per module) so > > that it will be easy to review and adjust the approach as needed. > > > > Thoughts? > > > > d > > > >> > >> -- > >> Soren Hansen | http://linux2go.dk/ > >> Ubuntu Developer | http://www.ubuntu.com/ > >> OpenStack Developer | http://www.openstack.org/ > >> > >> _______________________________________________ > >> Mailing list: https://launchpad.net/~openstack > >> Post to : openstack@lists.launchpad.net > >> Unsubscribe : https://launchpad.net/~openstack > >> More help : https://help.launchpad.net/ListHelp > > > > _______________________________________________ > > Mailing list: https://launchpad.net/~openstack > > Post to : openstack@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~openstack > > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
