Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #40422 > unrolled thread

How to prevent tests from running against production?

Back to article view | Back to comp.lang.python

Contents

  How to prevent tests from running against production? Roy Smith <roy@panix.com> - 2013-03-03 16:56 -0500
    Re: How to prevent tests from running against production? Ross Ridge <rridge@csclub.uwaterloo.ca> - 2013-03-03 23:30 -0500
    Re: How to prevent tests from running against production? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-03-04 07:05 +0000

#40422 — How to prevent tests from running against production?

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.

[toc] | [next] | [standalone]

#40433

Roy Smith  <roy@panix.com> 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]  rridge@csclub.uwaterloo.ca
-()-/()/  http://www.csclub.uwaterloo.ca/~rridge/ 
 db  //	  

[toc] | [prev] | [next] | [standalone]

#40434

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web