skipUnlessDBFeature(*feature_name_strings) [source] Skip the decorated test or TestCase if any of the named database features are not supported. For example, the following test will only be executed if the database supports transactions (e.g., it would run under PostgreSQL, but not under MySQL with MyISAM tables): class MyTests(TestCase): @skipUnlessDBFeature('supports_transactions') def test_transaction_behavior(self): # ... conditional test code pass

skipIfDBFeature(*feature_name_strings) [source] Skip the decorated test or TestCase if all of the named database features are supported. For example, the following test will not be executed if the database supports transactions (e.g., it would not run under PostgreSQL, but it would under MySQL with MyISAM tables): class MyTests(TestCase): @skipIfDBFeature('supports_transactions') def test_transaction_behavior(self): # ... conditional test code pass

class TestCase [source] This is the most common class to use for writing tests in Django. It inherits from TransactionTestCase (and by extension SimpleTestCase). If your Django application doesn’t use a database, use SimpleTestCase. The class: Wraps the tests within two nested atomic() blocks: one for the whole class and one for each test. Therefore, if you want to test some specific database transaction behavior, use TransactionTestCase. Checks deferrable database constraints at the end of

class TransactionTestCase [source] TransactionTestCase inherits from SimpleTestCase to add some database-specific features: Resetting the database to a known state at the beginning of each test to ease testing and using the ORM. Database fixtures. Test skipping based on database backend features. The remaining specialized assert* methods. Django’s TestCase class is a more commonly used subclass of TransactionTestCase that makes use of database transaction facilities to speed up the process

SimpleTestCase.client Every test case in a django.test.*TestCase instance has access to an instance of a Django test client. This client can be accessed as self.client. This client is recreated for each test, so you don’t have to worry about state (such as cookies) carrying over from one test to another. This means, instead of instantiating a Client in each test: import unittest from django.test import Client class SimpleTest(unittest.TestCase): def test_details(self): client =

SimpleTestCase.settings() [source] For testing purposes it’s often useful to change a setting temporarily and revert to the original value after running the testing code. For this use case Django provides a standard Python context manager (see PEP 343) called settings(), which can be used like this: from django.test import TestCase class LoginTestCase(TestCase): def test_login(self): # First check for the default behavior response = self.client.get('/sekrit/')

SimpleTestCase.client_class If you want to use a different Client class (for example, a subclass with customized behavior), use the client_class class attribute: from django.test import TestCase, Client class MyTestClient(Client): # Specialized methods for your environment ... class MyTest(TestCase): client_class = MyTestClient def test_my_stuff(self): # Here self.client is an instance of MyTestClient... call_some_test_code()

SimpleTestCase.assertXMLNotEqual(xml1, xml2, msg=None) [source] Asserts that the strings xml1 and xml2 are not equal. The comparison is based on XML semantics. See assertXMLEqual() for details. Output in case of error can be customized with the msg argument.

SimpleTestCase.modify_settings() [source] It can prove unwieldy to redefine settings that contain a list of values. In practice, adding or removing values is often sufficient. The modify_settings() context manager makes it easy: from django.test import TestCase class MiddlewareTestCase(TestCase): def test_cache_middleware(self): with self.modify_settings(MIDDLEWARE={ 'append': 'django.middleware.cache.FetchFromCacheMiddleware', 'prepend': 'django.middlew

SimpleTestCase.assertRaisesMessage(expected_exception, expected_message, callable, *args, **kwargs) [source] SimpleTestCase.assertRaisesMessage(expected_exception, expected_message) Asserts that execution of callable raises expected_exception and that expected_message is found in the exception’s message. Any other outcome is reported as a failure. It’s a simpler version of unittest.TestCase.assertRaisesRegex() with the difference that expected_message isn’t treated as a regular expression.