    and one for each test.
  
  * Checks deferrable database constraints at the end of each test.
  
  * Creates a TestClient instance.
  
  * Django-specific assertions for testing for things like redirection and form
    errors.
  
  .. versionchanged:: 1.10
  
      The check for deferrable database constraints at the end of each test was
      added.
  
 
</s> remove * Automatic loading of fixtures.

* Wraps the tests within two nested ``atomic`` blocks: one for the whole class
  and one for each test.
 </s> add * Wraps the tests within two nested :func:`~django.db.transaction.atomic`
  blocks: one for the whole class and one for each test. Therefore, if you want
  to test some specific database transaction behavior, use
  :class:`TransactionTestCase`. </s> remove Converting a normal :class:`unittest.TestCase` to a Django :class:`TestCase` is
easy: Just change the base class of your test from ``'unittest.TestCase'`` to
``'django.test.TestCase'``. All of the standard Python unit test functionality
will continue to be available, but it will be augmented with some useful
additions, including:
 </s> add The class: </s> remove Django's ``TestCase`` class (described below) makes use of database transaction
facilities to speed up the process of resetting the database to a known state
at the beginning of each test. A consequence of this, however, is that some
database behaviors cannot be tested within a Django ``TestCase`` class. For
instance, you cannot test that a block of code is executing within a
transaction, as is required when using
 </s> add ``TransactionTestCase`` inherits from :class:`~django.test.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 :attr:`~TransactionTestCase.fixtures`.
* Test :ref:`skipping based on database backend features <skipping-tests>`.
* The remaining specialized :meth:`assert*
  <TransactionTestCase.assertQuerysetEqual>` methods.

Django's :class:`TestCase` class is a more commonly used subclass of
``TransactionTestCase`` that makes use of database transaction facilities
to speed up the process of resetting the database to a known state at the
beginning of each test. A consequence of this, however, is that some database
behaviors cannot be tested within a Django ``TestCase`` class. For instance,
you cannot test that a block of code is executing within a transaction, as is
required when using </s> remove This class provides some additional capabilities that can be useful for testing
websites.
 </s> add This is the most common class to use for writing tests in Django. It inherits
from :class:`TransactionTestCase` (and by extension :class:`SimpleTestCase`).
If your Django application doesn't use a database, use :class:`SimpleTestCase`.
    and one for each test.
  
  * Checks deferrable database constraints at the end of each test.
  





  .. versionchanged:: 1.10
  
      The check for deferrable database constraints at the end of each test was
      added.
  
keep keep keep keep replace replace replace replace replace keep keep keep keep keep
 Refs #26270 -- Reorganized TestCase docs. 
docs/topics/testing/tools.txt