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. 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.
- 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
