Skip to content
Browse files

[soc2010/test-refactor] Update docs to reflect unittest2 changes.

  • Loading branch information...
1 parent 5875c4e commit 0620a1c223bc6bd7b83756376eccd68362610826 @PaulMcMillan PaulMcMillan committed Aug 5, 2010
Showing with 13 additions and 8 deletions.
  1. +4 −3 docs/internals/contributing.txt
  2. +9 −5 docs/topics/testing.txt
View
7 docs/internals/contributing.txt
@@ -825,9 +825,10 @@ The tests cover:
We appreciate any and all contributions to the test suite!
The Django tests all use the testing infrastructure that ships with
-Django for testing applications. New tests should use the unittest
-framework. See :ref:`Testing Django applications <topics-testing>` for
-an explanation of how to write new tests.
+Django for testing applications. New tests should use
+``django.utils.unittest``, and should not include doctests. See
+:ref:`Testing Django applications <topics-testing>` for an explanation
+of how to write new tests.
Running the unit tests
----------------------
View
14 docs/topics/testing.txt
@@ -52,9 +52,9 @@ frameworks are:
return a_list[idx]
* **Unit tests** -- tests that are expressed as methods on a Python class
- that subclasses ``unittest.TestCase``. For example::
+ that subclasses ``django.utils.unittest.TestCase``. For example::
- import unittest
+ from django.utils import unittest
class MyFuncTestCase(unittest.TestCase):
def testBasic(self):
@@ -157,6 +157,8 @@ Like doctests, Django's unit tests use a standard library module: unittest_.
This module uses a different way of defining tests, taking a class-based
approach.
+.. versionchanged:: 1.3 Django bundles the Python 2.7 unittest library as ``django.utils.unittest``. You can still use the system ``unittest`` package, but the the bundled package includes more verbose error reporting and additional assertions for versions of Python below 2.7.
+
As with doctests, for a given Django application, the test runner looks for
unit tests in two places:
@@ -170,7 +172,7 @@ unit tests in two places:
This example ``unittest.TestCase`` subclass is equivalent to the example given
in the doctest section above::
- import unittest
+ from django.utils import unittest
from myapp.models import Animal
class AnimalTestCase(unittest.TestCase):
@@ -233,6 +235,8 @@ you:
routines, which give you a high level of control over the environment
in which your test cases are run.
+ * If you're writing tests for Django itself, you should use ``unittest``.
+
Again, remember that you can use both systems side-by-side (even in the same
app). In the end, most projects will eventually end up using both. Each shines
in different circumstances.
@@ -913,7 +917,7 @@ Example
The following is a simple unit test using the test client::
- import unittest
+ from django.utils import unittest
from django.test.client import Client
class SimpleTest(unittest.TestCase):
@@ -1010,7 +1014,7 @@ 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.utils import unittest
from django.test.client import Client
class SimpleTest(unittest.TestCase):

0 comments on commit 0620a1c

Please sign in to comment.
Something went wrong with that request. Please try again.