Client.session A dictionary-like object containing session information. See the session documentation for full details. To modify the session and then save it, it must be stored in a variable first (because a new SessionStore is created every time this property is accessed): def test_something(self): session = self.client.session session['somekey'] = 'test' session.save()

trace(path, follow=False, secure=False, **extra) [source] Makes a TRACE request on the provided path and returns a Response object. Useful for simulating diagnostic probes. Unlike the other request methods, data is not provided as a keyword parameter in order to comply with RFC 7231#section-4.3.8, which mandates that TRACE requests must not have a body. The follow, secure, and extra arguments act the same as for Client.get().

class LiveServerTestCase [source] LiveServerTestCase does basically the same as TransactionTestCase with one extra feature: it launches a live Django server in the background on setup, and shuts it down on teardown. This allows the use of automated test clients other than the Django dummy client such as, for example, the Selenium client, to execute a series of functional tests inside a browser and simulate a real user’s actions. By default the live server listens on localhost and picks the f

modify_settings() [source] Likewise, Django provides the modify_settings() decorator: from django.test import TestCase, modify_settings class MiddlewareTestCase(TestCase): @modify_settings(MIDDLEWARE={ 'append': 'django.middleware.cache.FetchFromCacheMiddleware', 'prepend': 'django.middleware.cache.UpdateCacheMiddleware', }) def test_cache_middleware(self): response = self.client.get('/') # ... The decorator can also be applied to test case clas

override_settings() [source] In case you want to override a setting for a test method, Django provides the override_settings() decorator (see PEP 318). It’s used like this: from django.test import TestCase, override_settings class LoginTestCase(TestCase): @override_settings(LOGIN_URL='/other/login/') def test_login(self): response = self.client.get('/sekrit/') self.assertRedirects(response, '/other/login/?next=/sekrit/') The decorator can also be applied to TestCas

class RequestFactory [source] The RequestFactory shares the same API as the test client. However, instead of behaving like a browser, the RequestFactory provides a way to generate a request instance that can be used as the first argument to any view. This means you can test a view function the same way as you would test any other function – as a black box, with exactly known inputs, testing for specific outputs. The API for the RequestFactory is a slightly restricted subset of the test clien

class Response client The test client that was used to make the request that resulted in the response. content The body of the response, as a bytestring. This is the final page content as rendered by the view, or any error message. context The template Context instance that was used to render the template that produced the response content. If the rendered page used multiple templates, then context will be a list of Context objects, in the order in which they were rendered. Re

client The test client that was used to make the request that resulted in the response.

content The body of the response, as a bytestring. This is the final page content as rendered by the view, or any error message.

context The template Context instance that was used to render the template that produced the response content. If the rendered page used multiple templates, then context will be a list of Context objects, in the order in which they were rendered. Regardless of the number of templates used during rendering, you can retrieve context values using the [] operator. For example, the context variable name could be retrieved using: >>> response = client.get('/foo/') >>> response.co