Ticket #17312: 17312.diff

docs/topics/testing.txt

@@ -115 +115 @@
 
     class AnimalTestCase(unittest.TestCase):
         def setUp(self):
-            self.lion = Animal.objects.create(name="lion", sound="roar")
-            self.cat = Animal.objects.create(name="cat", sound="meow")
+            self.lion = Animal(name="lion", sound="roar")
+            self.cat = Animal(name="cat", sound="meow")
 
         def test_animals_can_speak(self):
             """Animals that can speak are correctly identified"""
@@ -139 +139 @@
 
 .. _suggested organization: http://docs.python.org/library/unittest.html#organizing-tests
 
+.. warning::
+
+    If your tests rely on database access such as creating or querying models,
+    be sure to create your test classes as subclasses of
+    :class:`django.test.TestCase` rather than :class:`unittest.TestCase`.
+
+    In the example above, we instantiate some models but do not save them to
+    the database. Using :class:`unittest.TestCase` avoids the cost of running
+    each test in a transaction and flushing the database, but for most
+    applications the scope of tests you will be able to write this way will
+    be fairly limited, so it's easiest to use :class:`django.test.TestCase`.
+
 Writing doctests
 ----------------
 
@@ -343 +355 @@
 Django features into modes that allow for repeatable testing.
 
 The call to :meth:`~django.test.utils.setup_test_environment` is made
-automatically as part of the setup of `./manage.py test`. You only
+automatically as part of the setup of ``./manage.py test``. You only
 need to manually invoke this method if you're not using running your
 tests via Django's test runner.
 
@@ -1385 +1397 @@
 
         def test_my_stuff(self):
             # Here self.client is an instance of MyTestClient...
+            call_some_test_code()
 
 .. _topics-testing-fixtures: