Pandas CI: create/drop pandas_nosetest db on class instatiation

So I think that the SQL test classes should inherit from:

https://github.com/pydata/pandas/blob/master/pandas/util/testing.py#L65

then you can add

class BaseSQLTestCase(tm.TestCase):

   @classmethod
    def setUpClass(cls):
        super(BaseSQLTestCase, cls).setUpClass()

        # create the ``pandas_nosetest`` db here

   @classmethod
    def tearDownClass(cls):
        super(BaseSQLTestCase, cls).tearDownClass()

        # drop the ``pandas_nosetest`` db here

and remove this: https://github.com/pydata/pandas/blob/master/.travis.yml#L100

This doesn't affect travis, but testing on a static platform (e.g. windows) where the database in theory could have something in it (if a test was stopped in the middle) and then the next time it runs their is stuff there

Comment From: jorisvandenbossche

@jreback If a test fails, then the tearDown function is not called anymore? Because normally this should assure there are no tables in the database for the following test (eg https://github.com/pydata/pandas/blob/master/pandas/io/tests/test_sql.py#L971)

Comment From: jreback

no it is but if the script is interrupted in the middle of test (and for some reason these take a while on windows) then it could be in an uknown state

more important I think is that no sql tests can be run by users because they almost certainly don't have the correct database created

not sure if that is an issue

Comment From: jorisvandenbossche

The reason I would rather not do this, is that the tests aren't already that fast, and this will likely slow it down? We could also check for existing tables in the setUp after connecting (for case of interruption)?

About having the correct database created for users who run the tests, that is indeed a problem. But I think you will have to configure your setup in any case a bit manually. As it is also not that likely that you have the exact same username/password as what is used in the tests. In that case it is not much work to once create the database I think.

Comment From: jorisvandenbossche

Ah, but you meant a setupClass, so not for every test. So my speed argument is not valid.

Comment From: jreback

yeh....once for each class (its not really a big deal). though maybe include some method of haveing a user configure the db's and such so they can actually run the tests locally (not sure how to do this) e.g. a method of specifying to nose your db configuration (maybe sqlalchemy has something for this)?