«

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.

It's easy to write a check like that in setup(), but that only gets
called if you remember to write a setup() method (or inherit from
something that does). I'm looking for something that runs completely
automatically. I don't want somebody to be able to write something
which causes damage that nose can discover and run when you're connected
to the wrong database.

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.

Having your tests use credentials that don't work in the production
environment would seem to be the obvious solution.

Ross Ridge

--
l/ // Ross Ridge -- The Great HTMU
[oo][oo]
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //

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:

class MyTestCase(unittest.TestCase):
def __init__(self, *args, **kwargs):
if DATABASE == 'Production':
import webbrowser
webbrowser.open("http://i.imgur.com/y7Hm9.jpg", new=1)
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.



--
Steven