Skip to main content

Instant integration of Ian Bicking's WebTest (http://pythonpaste.org/webtest/) with django's testing framework.

Project description

django-webtest is an app for instant integration of Ian Bicking’s WebTest (http://webtest.pythonpaste.org/) with django’s testing framework.

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 (WebTest) that creates webtest.TestApp around django wsgi interface and make 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.

Unlike django’s native test client CSRF checks are not suppressed by default so missing CSRF tokens will cause test fails (and that’s good).

If forms are submitted via WebTest forms API then all form fields (including CSRF token) are submitted automagically:

class AuthTest(WebTest):
    fixtures = ['users.json']

    def test_login(self)
        form = self.app.get(reverse('auth_login')).form
        form['username'] = 'foo'
        form['password'] = 'bar'
        response = form.submit().follow()
        self.assertEqual(response.context['user'].username, 'foo')

However if forms are submitted via raw POST requests using app.post then csrf tokens become hard to construct. CSRF checks can be disabled by setting csrf_checks attribute to False in this case:

class MyTestCase(WebTest):
    csrf_checks = False
    def test_post(self)
        self.app.post('/')

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.

See http://webtest.pythonpaste.org/ for API help. It can follow links, submit forms, parse html, xml and json responses with different parsing libraries, upload files and more.

Installation

$ pip install webtest
$ pip install django-webtest

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.

CHANGES

1.5 (2012-02-24)

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

  • don’t list python 2.5 as supported because WebOb dropped 2.5 support;

  • python 3 support;

  • test running using tox.

1.4.4 (2012-02-08)

  • ‘user’ parameter for self.app.put and self.app.delete methods.

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:

    DEBUG_MIDDLEWARE = 'debug_toolbar.middleware.DebugToolbarMiddleware'
    if DEBUG_MIDDLEWARE in MIDDLEWARE_CLASSES:
        MIDDLEWARE_CLASSES.remove(DEBUG_MIDDLEWARE)

1.4.1 (2011-06-29)

  • self.renew_app() method for resetting the ‘browser’ inside tests.

1.4 (2011-06-23)

  • Better auth implementation;

  • support for assertRedirects, assertContains and assertNotContains.

1.3 (2010-12-31)

  • Django 1.3 compatibility: test responses are now having ‘templates’ attribute;

  • Django 1.3 compatibility: the way exceptions are handled is changed;

  • auto_follow parameter for app.get method (redirect chains will be auto-followed with auto_follow=True).

1.2.1 (2010-08-24)

  • REMOTE_USER authorization can be disabled.

1.2 (2010-08-21)

  • response.template and response.context goodness (thanks Gregor Müllegger);

  • tests (thanks Gregor Müllegger);

  • csrf checks are now optional (thanks Gregor Müllegger).

1.1.1 (2010-07-16)

  • User instance can be passed to get and post methods instead of user’s username.

1.1 (2010-06-15)

  • Original traceback instead of html 500 error page;

  • per-TestCase extra_environ (thanks Gael Pasgrimaud);

  • fixed a bug with app.post parameters (thanks anonymous).

1.0 (2010-04-20)

Initial release (thanks Ian Bicking for WebTest).

Project details


Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

django-webtest-1.5.tar.gz (8.9 kB view details)

Uploaded Source

File details

Details for the file django-webtest-1.5.tar.gz.

File metadata

File hashes

Hashes for django-webtest-1.5.tar.gz
Algorithm Hash digest
SHA256 266a1ac1aa15f88a89e271c6f4c6218000c77f77d48b704577801c6e63f47e17
MD5 5cfdbd8eeba616bfe4067291c7fecfea
BLAKE2b-256 c4e5735c1e94750d689177132c43e6067eff0e183a432375efeb0d5a68d59c60

See more details on using hashes here.

Supported by

AWS AWS Cloud computing and Security Sponsor Datadog Datadog Monitoring Fastly Fastly CDN Google Google Download Analytics Microsoft Microsoft PSF Sponsor Pingdom Pingdom Monitoring Sentry Sentry Error logging StatusPage StatusPage Status page