[Solved]-How to set up a django test server when using gunicorn?

I’ve read the code. Looking at LiveServerTestCase for inspiration makes sense but trying to cook up something by extending or somehow calling LiveServerTestCase is asking for trouble and increased maintenance costs.

A robust way to run which looks like what LiveServerTestCase does is to create from unittest.TestCase a test case class with custom setUpClass and tearDownClass methods. The setUpClass method:

1. Sets up an instance of the Django application with settings appropriate for testing: a database in a location that won’t interfere with anything else, logs recorded to the appropriate place and, if emails are sent during normal operations, with emails settings that won’t make your sysadmins want to strangle you, etc.

   [In effect, this is a deployment procedure. Since we want to eventually deploy our application, the process above is one which we should develop anyway.]

2. Load whatever fixtures are necessary into the database.

3. Starts a Gunicorn instance run this instance of the Django application, using the usual OS commands for this.

The tearDownClass:

1. Shuts down the Gunicorn instance, again using normal OS commands.

2. Deletes the database that was created for testing, deletes whatever log files may have been created, etc.

And between the setup and teardown our tests contact the application on the port assigned to Gunicorn and they load more fixtures if needed, etc.

Why not try to use a modified LiveServerTestCase?

1. LiveServerTestCase includes the entire test setup in one process: the tests, the WSGI server and the Django application. Gunicorn is not designed for operating like this. For one thing, it uses a master process and worker processes.

2. If LiveServerTestCase is modified to somehow start the Django app in an external process, then a good deal of the benefits of this class go out the window. LiveServerTestCase relies on the fact that it can just modifies settings or database connections in its process space and that these modifications will carry over to the Django app, because it lives in the same process. If the app is in a different process, these tricks can’t work. Once LiveServerTestCase is modified to take care of this, the end result is close to what I’ve outlined above.

Additional: Could someone get Gunicorn and Django to run in the same process?

I’m sure someone could glue them together, but consider the following. This would certainly mean changing the core code of Gunicorn since Gunicorn is designed to use master and worker processes. Then, this person who created the glue would be responsible for keeping this glue up to date when Gunicorn or Django’s internals change in such a way that makes the glue break. At the end of the day doing this requires more work than using the method outlined at the start of this answer.

Off top of my head, you can try to override LiveServerTestCase.setUpClass and wind up gunicorn instead of LiveServerThread