Installation

Usage

from django_webtest import WebTest
class MyTestCase(WebTest):
# optional: we want some initial data to be able to login
fixtures = ['users', 'blog_posts']
# optional: default extra_environ for this TestCase
extra_environ = {'HTTP_ACCEPT_LANGUAGE': 'ru'}
def testBlog(self):
# pretend to be logged in as user `kmike` and go to the index page
index = self.app.get('/', user='kmike')
# All the webtest API is available. For example, we click
# on a <a href='/tech-blog/'>Blog</a> link, check that it
# works (result page doesn't raise exceptions and returns 200 http
# code) and test if result page have 'My Article' text in
# it's body.
assert 'My Article' in index.click('Blog')

django-webtest provides django.test.TestCase subclass
(django_webtest.WebTest) that creates webtest.TestApp around
django wsgi interface and makes it available in tests as self.app.

It also features optional user argument for self.app.get and
self.app.post methods to help making authorized requests. This argument
should be django.contrib.auth.models.User instance or a string with user’s
username for user who is supposed to be logged in.

For 500 errors original traceback is shown instead of usual html result
from handler500.

You also get the response.templates and response.context goodness that
is usually only available if you use django’s native test client. These
attributes contain a list of templates that were used to render the response
and the context used to render these templates. All django’s native asserts (
assertFormError, assertTemplateUsed, assertTemplateNotUsed,
assertContains, assertNotContains, assertRedirects) are
also supported for WebTest responses.

The session dictionary is available via self.app.session, and has the
content as django’s native test client.

When a subclass of django’s TransactionTestCase is desired,
use django_webtest.TransactionWebTest.

All of these features can be easily set up manually (thanks to WebTest
architecture) and they are even not neccessary for using WebTest with django but
it is nice to have some sort of integration instantly.

Why?

While django.test.client.Client is fine for it’s purposes, it is not
well-suited for functional or integration testing. From django’s test client
docstring:

This is not intended as a replacement for Twill/Selenium or
the like - it is here to allow testing against the
contexts and templates produced by a view, rather than the
HTML rendered to the end-user.

WebTest plays on the same field as twill. WebTest has nice API, is fast, small,
talk to django application via WSGI instead of HTTP and is an easy way to
write functional/integration/acceptance tests.

Twill is also a great tool and it also can be easily integrated with django
(see django-test-utils package) and I also enjoy it much. But I prefer WebTest
over twill because twill is old (last release is in 2007), communicate via HTTP
instead of WSGI (though there is workaround for that), lacks support for
unicode and have a much larger codebase to hack on. django-webtest also
is able to provide access to the names of rendered templates and
template context just like native django TestClient. Twill however understands
HTML better and is more mature so consider it if WebTest doesn’t fit for
some reason.

1.5.5 (2013-01-14)

1.5.4 (2012-09-13)

tox.ini is updated to use latest django versions and the
official trunk with python3 support;

django 1.5 SimpleCookie issues are fixed.

1.5.3 (2012-04-25)

self.assertRedirects is fixed for authenticated requests.

1.5.2 (2012-04-01)

if AuthenticationMiddleware is not in a middleware list,
WebtestUserMiddleware is put to the end of middlewares in order to
provide better backward compatibility with 1.4.x in case of custom
auth middlewares.

1.5.1 (2012-03-22)

Fixed handling of forms with method=”get”. Thanks Jeroen Vloothuis.

1.5 (2012-02-24)

WebtestUserMiddleware is inserted after AuthenticationMiddleware, not to
the end of middleware list (thanks bigkevmcd);

1.4.4 (2012-02-08)

1.4.3 (2011-09-27)

The django session dictionary is available via self.app.session.

1.4.2 (2011-08-26)

REMOTE_ADDR is now '127.0.0.1' by default. This is how
standard django’s test client behave.

Please note that this can slow tests down and cause other side effects
if django-debug-toolbar 0.9.x is installed+configured and
INTERNAL_IPS contain '127.0.0.1' because debug toolbar will
become turned on during tests. The workaround is to remove
django-debug-toolbar middleware during tests in your test settings: