Thanks for including a link to the TDD tutorial!

As far as I can tell, the author wants to use `--liveserver` to point his 
functional tests at an external server so he can run his tests through 
nginx after running the same tests in his normal test environment. Based on 
the shell prompts in
I think he intends to have the database and code running on his staging 
server while he runs his tests locally. He also avoids the 
TransactionTestCase truncation operations by shorting out the 
LiveServerTestCase setUp / tearDownClass.

Simplest way?
The simplest way I can think of to resolve the issue is to read the 
external liveserver out of os.env instead of sys.argv. Then you can follow 
along exactly.
$ python test

`allow_database_queries = False` would make me trust the setUpClass / 
tearDownClass overrides more but my main issue with this approach is that 
it does a lot of extra work: 

   1. run tests locally
   2. deploy to your code to your staging server
   3. runserver with fixed port on staging server
   4. run tests locally with LiveServerTestCases running against staging 

It would be nice for the last run-through to _only_ run the functional 
tests and not have to setUp the local database or run the other tests 
against your local branch.

Make unittest run functional tests remotely

# app/
import os

    from django.tests import StaticLiveServerTestCase
    FunctionalTest = StaticLiveServerTestCase
    class FunctionalTest(unittest.TestCase):
        live_server_url = ''

then you can either run the tests via the DiscoveryRunner on the local 
$ python test

or via the normal unittest runner on your remote server
$ python -m unittest discover -p 'test_functional_*.py'

Unfortunately, you'll lose a lot of power in not being able to reuse your 
form code, assert anything about the database state on the remote server, 
access django assertion methods, ... 
At that point, I'd probably just run the tests on the remove server and do 
something like

Hardcode the port
class FixedPortServerThread(LiveServerThread):
    def _create_server(self, port):
         if os.env.get('THROUGH_NGINX'):
             return super(FixedPortServerThread, self)._create_server(port=
             return super(FixedPortServerThread, self)._create_server(port=

class MyLiveServerTestCase(LiveServerTestCase):
    server_thread_class = FixedPortServerThread

On Saturday, October 15, 2016 at 9:32:54 AM UTC-4, Andrew Wall wrote:

> Very much appreciate the Django framework.  
> I noticed in the docs 
> <>
> for Django 1.11 that the *DJANGO_LIVE_TEST_SERVER_ADDRESS* environmental 
> variable is slated to be removed, along with the accompanying 
> python test *--liveserver* option.  I'm concerned that without 
> the ability to specify a remote IP address using --liveserver, it will no 
> longer be possible to run functional tests using selenium against an 
> external server.  I learned this technique from Harry Percival's excellent 
> TDD with Python (see 
> where the test command is called from the local machine but you pass in the 
> external IP.  Will there be a different way to do this in Django 1.11? 
> Perhaps the change to bind LiveserverTestCase to port zero by default can 
> be made while retaining the option to pass in --liveserver?  Realize the 
> release is a ways away but would appreciate any help as I've come to rely 
> on this method to test server deployments.  Thank you!

You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
To post to this group, send email to
Visit this group at
To view this discussion on the web visit
For more options, visit

Reply via email to