In the real world, a django application may be deployed on a real production plateform with as many layers as needed:
WSGI server
proxy
…
When we write functional tests with the dummy web client, we do not cover what’s going on over all those layers that composed application globality.
Also, in the real world, we use web client intances such as browsers like chromium, opera, IE… to deal with the application over HTTP and we want our application to run correctly on all those clients.
Another important point is the use of client side javascripts: when we use the dummy client, we can’t test javascripts.
That’s why we need to write functionnal tests that cover real world constraints.
To simply illustrate this, I’ve made a simple (useless) application composed of a single user story:
As an anonymous user, I can write a message, then the message is displayed in a list with the nine latest messages.
models.py:
views.py:
Ok, now, I’ll write a functional test case basically using the dummy client:
Ok, the application now works correctly, but I think it’s gonna be better to do the job ansynchronous. So, let’s add a piece of javascript:
and then modify views.py to feet my need:
Now my application works correctly even when javascript is disabled. Now it’s gonna be cool to write a functionnal test to cover that.
LiveServerTestCase
Django 1.4 introduced a new test class called LiveServerTestCase that extends TransactionTestCase.
This new test class launches the application in a real WSGI server instance into an asynchronous thread. As it’s a real server, we can easily write tests within real web browser instances.
There are many solutions providing python backends (Ghost.py, Selenium…), here I’m gonna use Selenium.
So, I had a new (minimalist) test case:
As you can see, we can deal with database and browser in the same script…