Browse files

[1.5.x] Fixed #20165 - Updated testing example to use django.test.Tes…


Thanks Lorin Hochstein.

Backport of 84d8b24 from master.
  • Loading branch information...
1 parent 20bed77 commit 7f4269229cd6ca0ef94a34fd045e3ced9bdd57d0 @timgraham timgraham committed May 15, 2013
Showing with 16 additions and 12 deletions.
  1. +16 −12 docs/topics/testing/overview.txt
@@ -56,20 +56,24 @@ places:
directory that holds ````. Again, the test runner looks for any
subclass of :class:`unittest.TestCase` in this module.
-Here is an example :class:`unittest.TestCase` subclass::
+Here is an example which subclasses from :class:`django.test.TestCase`,
+which is a subclass of :class:`unittest.TestCase` that runs each test inside a
+transaction to provide isolation::
- from django.utils import unittest
+ from django.test import TestCase
from myapp.models import Animal
- class AnimalTestCase(unittest.TestCase):
+ class AnimalTestCase(TestCase):
def setUp(self):
- self.lion = Animal(name="lion", sound="roar")
- = Animal(name="cat", sound="meow")
+ Animal.objects.create(name="lion", sound="roar")
+ Animal.objects.create(name="cat", sound="meow")
def test_animals_can_speak(self):
"""Animals that can speak are correctly identified"""
- self.assertEqual(self.lion.speak(), 'The lion says "roar"')
- self.assertEqual(, 'The cat says "meow"')
+ lion = Animal.objects.get(name="lion")
+ cat = Animal.objects.get(name="cat")
+ self.assertEqual(lion.speak(), 'The lion says "roar"')
+ self.assertEqual(cat.speak(), 'The cat says "meow"')
When you :ref:`run your tests <running-tests>`, the default behavior of the test
utility is to find all the test cases (that is, subclasses of
@@ -93,11 +97,11 @@ For more details about :mod:`unittest`, see the Python documentation.
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`.
+ Using :class:`unittest.TestCase` avoids the cost of running each test in a
+ transaction and flushing the database, but if your tests interact with
+ the database their behavior will vary based on the order that the test
+ runner executes them. This can lead to unit tests that pass when run in
+ isolation but fail when run in a suite.
.. _running-tests:

0 comments on commit 7f42692

Please sign in to comment.