56
56
directory that holds ``models.py``. Again, the test runner looks for any
57
57
subclass of :class:`unittest.TestCase` in this module.
59
Here is an example :class:`unittest.TestCase` subclass::
59
Here is an example which subclasses from :class:`django.test.TestCase`,
60
which is a subclass of :class:`unittest.TestCase` that runs each test inside a
61
transaction to provide isolation::
61
from django.utils import unittest
63
from django.test import TestCase
62
64
from myapp.models import Animal
64
class AnimalTestCase(unittest.TestCase):
66
class AnimalTestCase(TestCase):
66
self.lion = Animal(name="lion", sound="roar")
67
self.cat = Animal(name="cat", sound="meow")
68
Animal.objects.create(name="lion", sound="roar")
69
Animal.objects.create(name="cat", sound="meow")
69
71
def test_animals_can_speak(self):
70
72
"""Animals that can speak are correctly identified"""
71
self.assertEqual(self.lion.speak(), 'The lion says "roar"')
72
self.assertEqual(self.cat.speak(), 'The cat says "meow"')
73
lion = Animal.objects.get(name="lion")
74
cat = Animal.objects.get(name="cat")
75
self.assertEqual(lion.speak(), 'The lion says "roar"')
76
self.assertEqual(cat.speak(), 'The cat says "meow"')
74
78
When you :ref:`run your tests <running-tests>`, the default behavior of the test
75
79
utility is to find all the test cases (that is, subclasses of
93
97
be sure to create your test classes as subclasses of
94
98
:class:`django.test.TestCase` rather than :class:`unittest.TestCase`.
96
In the example above, we instantiate some models but do not save them to
97
the database. Using :class:`unittest.TestCase` avoids the cost of running
98
each test in a transaction and flushing the database, but for most
99
applications the scope of tests you will be able to write this way will
100
be fairly limited, so it's easiest to use :class:`django.test.TestCase`.
100
Using :class:`unittest.TestCase` avoids the cost of running each test in a
101
transaction and flushing the database, but if your tests interact with
102
the database their behavior will vary based on the order that the test
103
runner executes them. This can lead to unit tests that pass when run in
104
isolation but fail when run in a suite.
102
106
.. _running-tests:
907
911
* A ``TestCase``, on the other hand, does not truncate tables after a test.
908
912
Instead, it encloses the test code in a database transaction that is rolled
909
back at the end of the test. It also prevents the code under test from
910
issuing any commit or rollback operations on the database, to ensure that the
911
rollback at the end of the test restores the database to its initial state.
913
back at the end of the test. Both explicit commits like
914
``transaction.commit()`` and implicit ones that may be caused by
915
``Model.save()`` are replaced with a ``nop`` operation. This guarantees that
916
the rollback at the end of the test restores the database to its initial
913
919
When running on a database that does not support rollback (e.g. MySQL with the
914
920
MyISAM storage engine), ``TestCase`` falls back to initializing the database
915
921
by truncating tables and reloading initial data.
925
While ``commit`` and ``rollback`` operations still *appear* to work when
926
used in ``TestCase``, no actual commit or rollback will be performed by the
927
database. This can cause your tests to pass or fail unexpectedly. Always
928
use ``TransactionalTestCase`` when testing transactional behavior.
919
932
.. versionchanged:: 1.5
1096
1109
``LiveServerTestCase`` makes use of the :doc:`staticfiles contrib app
1097
</howto/static-files>` so you'll need to have your project configured
1110
</howto/static-files/index>` so you'll need to have your project configured
1098
1111
accordingly (in particular by setting :setting:`STATIC_URL`).
added
removed
docs/topics/testing/overview.txt
