Testing databases are not dropped after some tests

[Eva Balycheva]

Example of affected test class: https://github.com/openstack/zaqar/blob/master/zaqar/tests/unit/transport/websocket/v2/test_messages.py

After executing this test class, the databases still remain in filesystem, consuming space.

And also every time when I run "tox -e py27" two times in a row without a time delay between these commands, some tests fail on the second execution of "tox -e py27".
Examples of failed tests:
http://paste.openstack.org/show/2hvH6zHvz5xq6snNk19D/
http://paste.openstack.org/show/w91IKUOJ9hEO6eRowSIN/
If I manually wipe databases before running "tox -e py27" again, all tests pass.

Each invoke of tearDown() method just removes the created queue from one of the databases and checks if queue removal have returned the right status code in response. So the database is fresh and clean and can be reused by the remaining test methods. It's okay.

Exceptions are pools and catalogue databases which are always dropped on each invoke of tearDown(), if polling is enabled, because of the tearDown() method in parent test class:
See https://github.com/openstack/zaqar/blob/master/zaqar/tests/unit/transport/websocket/base.py#L52

But when no test methods left, the databases have to be dropped. But it doesn't happen.

So...
Possible solution for the affected test class:
Implement tearDownClass(cls) method which will be automatically invoked after all test class's methods finish their execution.
In this method all testing databases will be dropped.
See https://docs.python.org/2/library/unittest.html#unittest.TestCase.tearDownClass()
But currently tearDownClass(cls) method is not used anywhere in Zaqar's tests. Why is it avoided?

But maybe the behavior that keeps databases undropped was implemented on purpose and I just don't see why.

Fixing this bug will require a plenty of work, but...
1. Is it really a bug so it needs to be fixed?
2. Is the solution I proposed good? (I'm a newbie and maybe don't know something)

Please leave your thoughts in comments.

[Ryan Brown (sb-p)]

Yeah, I'm able to repro this locally. It would be great to have these cleaned up automatically.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/245464
Committed: https://git.openstack.org/cgit/openstack/zaqar/commit/?id=ea104e2eaf2a52ee598ee08215fddef2d3924b66
Submitter: Jenkins
Branch: master

commit ea104e2eaf2a52ee598ee08215fddef2d3924b66
Author: Eva Balycheva <email address hidden>
Date: Sat Nov 14 00:20:14 2015 +0300

    Automatically drop functional tests databases

    Currently some tests leave databases after execution.
    These databases consume significant amount of disk space.
    And sometimes their existence causes errors (see bug description)

    This patch partially solves the problem as it only affects functional
    tests.
    It will implement "tearDownClass(cls)" method in "FunctionalTestBase"
    class which will drop databases used by functional tests and close
    connections at the end of execution of each test subclass.

    Class method "_pooling_drop_dbs_by_project(cls, xproject)" uses not very
    straightforward way to drop databases of each pool driver, but it makes
    these databases to drop even in integration mode. Please tell me if you
    know a better way to do it.
    Cleanups in "TestHealth" class were removed as they prevent dropping of
    pool databases.

    But there's performance problem.
    The implementation of "tearDownClass(cls)" reopens connections to drop
    databases. Opening/closing connections consumes significant time.
    Same for dropping databases.
    Overall this patch makes functional test execution time +50% longer.
    On my machine it's: 20 seconds vs 27 seconds.

    I was searching for a solution to compensate this slowdown.
    Now I know super effective way to reduce functional tests execution time
    to just 5 seconds. The description of this possible solution can be
    found in my new bug report:
    https://bugs.launchpad.net/zaqar/+bug/1516343

    Partial-Bug: 1506091
    Change-Id: Ib4addfee5feadf8c75218da0cbeea56b0830f0a8