test.modify_settings()

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

test.LiveServerTestCase

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

test.Client.trace()

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().

test.Client.session

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()

test.Client.put()

put(path, data='', content_type='application/octet-stream', follow=False, secure=False, **extra) [source] Makes a PUT request on the provided path and returns a Response object. Useful for testing RESTful interfaces. When data is provided, it is used as the request body, and a Content-Type header is set to content_type. The follow, secure and extra arguments act the same as for Client.get().

test.Client.post()

post(path, data=None, content_type=MULTIPART_CONTENT, follow=False, secure=False, **extra) [source] Makes a POST request on the provided path and returns a Response object, which is documented below. The key-value pairs in the data dictionary are used to submit POST data. For example: >>> c = Client() >>> c.post('/login/', {'name': 'fred', 'passwd': 'secret'}) ...will result in the evaluation of a POST request to this URL: /login/ ...with this POST data: name=fred&pas

test.Client.patch()

patch(path, data='', content_type='application/octet-stream', follow=False, secure=False, **extra) [source] Makes a PATCH request on the provided path and returns a Response object. Useful for testing RESTful interfaces. The follow, secure and extra arguments act the same as for Client.get().

test.Client.options()

options(path, data='', content_type='application/octet-stream', follow=False, secure=False, **extra) [source] Makes an OPTIONS request on the provided path and returns a Response object. Useful for testing RESTful interfaces. When data is provided, it is used as the request body, and a Content-Type header is set to content_type. The follow, secure and extra arguments act the same as for Client.get().

test.Client.logout()

logout() [source] If your site uses Django’s authentication system, the logout() method can be used to simulate the effect of a user logging out of your site. After you call this method, the test client will have all the cookies and session data cleared to defaults. Subsequent requests will appear to come from an AnonymousUser.

test.Client.login()

login(**credentials) [source] If your site uses Django’s authentication system and you deal with logging in users, you can use the test client’s login() method to simulate the effect of a user logging into the site. After you call this method, the test client will have all the cookies and session data required to pass any login-based tests that may form part of a view. The format of the credentials argument depends on which authentication backend you’re using (which is configured by your AUT