[openstack-dev] [Quantum] Question on unit tests

Alex Meade alex.meade at rackspace.com
Wed Feb 6 21:02:07 UTC 2013


Hey Sal,
 
I'm not a Quantum dev but I may have some ideas. I'm sure most everyone knows that a lot of the projects have moved to using testr as the test runner in order to execute tests in parallel. Since that seems like something you guys are not moving to right away then maybe there is a quicker solution.
 
Have you seen 'eatmydata' (http://www.makelinux.net/man/1/E/eatmydata) I use it when running tests and it cuts the time in half. Just 'apt-get install eatmydata' if you're on ubuntu.
 
-Alex
 
-----Original Message-----
From: "Salvatore Orlando" <sorlando at nicira.com>
Sent: Wednesday, February 6, 2013 3:21pm
To: "OpenStack Development Mailing List" <openstack-dev at lists.openstack.org>
Subject: [openstack-dev] [Quantum] Question on unit tests



Hi,

As some of you have noticed, the number of unit tests arose to above
3,000 with recent merges.
The XML support is adding most of them, by doing something similar to
what the API tests for Quantum v1 did (execute the whole test cases
with both format).
While I understand and support this approach, there are two things to be noted:
- Unit test execution times have more than doubled
- With Quantum v2 we adopted a slightly different approach, by
separating API and DB tests. The formers tests (that we have for the
core API as well as many extensions) are the ones aimed at validating
correct serialization/deserialization. If we keep following this
approach, we might be able to save a lot of format-specific unit tests
for DB logic. From my perspective I don't think we will be losing any
coverage - but I might be missing something fundamental.

I recall Aaron and BobK in recent posts were suggesting to move to
parallel testing; this one of the first things we should address in
Havana. In the meanwhile, let me know if you think we can do something
to reduce the amount of resources used by unit tests.

I am also noticing that the memory leaks which were reduced a lot
during G-1 are hitting again, on low memory workers (2Gb); probably no
new leak has been introduced, it's just that the effect of the few
ones which were left it's now being felt more.

Salvatore

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130206/ced2d1f5/attachment.html>


More information about the OpenStack-dev mailing list