It'll be a couple days yet. I was refactoring a few things in the scheduler and while re-doing some tests, I ended up going down this rabbit hole of re-doing all of the tests. It's turned into a 6500 line diff so far... :) which is a bit much for just the refactoring that I need to get in first. So, I'm currently splitting these out into a couple of different reviews.
- Chris On Nov 30, 2011, at 1:53 PM, Duncan McGreggor wrote: > 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
