openstack team mailing list archive

[Duncan McGreggor <duncan@xxxxxxxxxxxxx>]

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