This test case creates a remote PostreSQL database provided by postgression.com. postgression.com provides you with a PostgreSQL database, so you don't need to set up a PostgreSQL server on your local machine.
Unfortunately, PostgreSQL only provides you with 100 Database per hour, which can be reached very quickly when running lots of tests at the same time. This is where this DatabaseTestCase comes into place. It stores information about the last database used on your machine and reuses it so you won't reach the limit of 100 database.
Just copy the TestCase class somewhere in your tests folder. Then import the class. Let's say you have a file called setupTests.py
in the test folder, the you would have to write:
from .setupTests import DatabaseTestCase
class MyTests(DatabaseTestCase):
def myTest(self):
host = self.postgreSQL_host
# your test goes here.
The TestCase has the following properties for that: postgreSQL_host
, postgreSQL_port
, postgreSQL_dbname
, postgreSQL_user
, postgreSQL_password
.
Since DatabaseTestCase
overrides setUp(self)
, you will need to call it from your class. Simply add super().setUp()
to the top of your custom setUp(self)
method.
Even if your tests take 3 hours, the Database will never expire. After each test, TestDatabase checks whether the database is older than 10 minutes and if so, it will create a new Database. So, if every tests take less than 20 minutes, you're good to go. If a test takes more than 20 minutes, you might want to split the test into different tests, anyway. It will make debugging easier, I promise :)
A database provided by postgression.com will expire after 30 minutes. By default DatabaseTestCase
will create a new Database if the last database is older than 10 minutes. So, as long as non of your tests take longer than 20 minutes, you're good to go. If one of your tests takes longer than 20 minutes the database may expire. You can change the maximal age of a database by override the max_database_age
property (simply add max_database_age = 600
to the top of your TestCase). Keep in mind that the age should be in seconds, not minutes.
If you want your database to last (less) longer, you will need to update the max_database_age
property. If you want your database to expire after one minute, you will need to have your class set up like this:
class MyTests(DatabaseTestCase):
max_database_age = 60 # in seconds
All information created by DatabaseTestCase are saved under .database.json
by default. If you need to save them somewhere else, update the property database_file
with the new path, as you would set max_database_age
.
Remember, the limit is set at 100 database per hour per IP. So, if one of your coworkers (who is on the same network) uses 95 Database, you only will only have 5 more to use. You can limit the databases you use by setting setting the max_database_age
to 25 minutes and you will only use 2 to 3 database per hour (you can find more information on how to do that in the FAQs). If all coworker use the same script, and you need to share it, you could set the database_file
to point to a shared network on each computer.
Sometime, you will mess up your Database due to a bug in your code. Your database may become unreliable and may not work as expected anymore. In this case you will need a new Database. You can do that by removing the .database.json
in your working directory. It will make the script request a new one from the
Well, even though you may want a complete new Database every time a test gets executed, it isn't that easy. Remember, you one have 100 databases per hour, so you can't get a new database for every test because If you have 60 tests (which isn't much), you could only run them all once per hour.
A good approach at solving this problem is using a transaction for every unit test and rollback after the test. If you can't do that, you could also override tearDown()
(don't forget to call super!) and truncate/drop all database but this is 2 times slower than a rollback.
If you really don't create if you reach the api limit, you can set the max_database_age
to 0, which causes the Database to load from the server every time a new test is executed (so, quite a few times).