openstack team mailing list archive

[Chris Behrens <chris.behrens@xxxxxxxxxxxxx>]

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 <duncan@xxxxxxxxxxxxx> wrote:
>> 
>>> On Tue, Nov 29, 2011 at 12:21 PM, Soren Hansen <soren@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~openstack
>>>> More help   : https://help.launchpad.net/ListHelp
>>> 
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp