How to prevent tests from running against production?
steve+comp.lang.python at pearwood.info
Mon Mar 4 08:05:19 CET 2013
On Sun, 03 Mar 2013 16:56:16 -0500, Roy Smith wrote:
> Our deploy/configuration system includes credentials for connecting to a
> database. We have one production database, and a variety of clones of
> that in our test and development environments.
> We've got a large body of tests, written with a combination of unittest
> and nose. Many of our tests do things which shouldn't be done against
> the production database. I'd like to set things up so anytime any test
> code gets run, a check is made to see which database you're connected to
> and if you're connect to production, the test refuses to run.
Test code is just code, so in general you can't guarantee to idiot-proof
your tests. Anyone can write a function, called by one of the tests,
which connects directly to the production database and does whatever they
want. But I assume you're not worried about malice.
One solution: create a single module, used by all tests, that handles
connection to the database. Simply don't have your connection module
connect to the database you don't want it to connect to. Since all tests
go through that module for connections, you can enforce whatever access
rules you like.
For added security, you should ensure that the production database does
not accept the same credentials as the test databases.
Another solution: instead of calling unittest.TestCase directly, write
your own subclass, then have all your tests use that:
def __init__(self, *args, **kwargs):
if DATABASE == 'Production':
raise RuntimeError("don't use production database")
super(MyTestCase, self).__init__(*args, **kwargs)
For added paranoia (and/or debugging fun), consider monkey-patching
unittest and/or nose.
More information about the Python-list