1
0
mirror of https://github.com/django/django.git synced 2025-07-05 02:09:13 +00:00

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

git-svn-id: http://code.djangoproject.com/svn/django/branches/soc2010/test-refactor@13477 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Paul McMillan 2010-08-05 04:23:03 +00:00
parent 5875c4e01c
commit 0620a1c223
2 changed files with 13 additions and 8 deletions

View File

@ -825,9 +825,10 @@ The tests cover:
We appreciate any and all contributions to the test suite! We appreciate any and all contributions to the test suite!
The Django tests all use the testing infrastructure that ships with The Django tests all use the testing infrastructure that ships with
Django for testing applications. New tests should use the unittest Django for testing applications. New tests should use
framework. See :ref:`Testing Django applications <topics-testing>` for ``django.utils.unittest``, and should not include doctests. See
an explanation of how to write new tests. :ref:`Testing Django applications <topics-testing>` for an explanation
of how to write new tests.
Running the unit tests Running the unit tests
---------------------- ----------------------

View File

@ -52,9 +52,9 @@ frameworks are:
return a_list[idx] return a_list[idx]
* **Unit tests** -- tests that are expressed as methods on a Python class * **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): class MyFuncTestCase(unittest.TestCase):
def testBasic(self): 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 This module uses a different way of defining tests, taking a class-based
approach. 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 As with doctests, for a given Django application, the test runner looks for
unit tests in two places: 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 This example ``unittest.TestCase`` subclass is equivalent to the example given
in the doctest section above:: in the doctest section above::
import unittest from django.utils import unittest
from myapp.models import Animal from myapp.models import Animal
class AnimalTestCase(unittest.TestCase): class AnimalTestCase(unittest.TestCase):
@ -233,6 +235,8 @@ you:
routines, which give you a high level of control over the environment routines, which give you a high level of control over the environment
in which your test cases are run. 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 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 app). In the end, most projects will eventually end up using both. Each shines
in different circumstances. in different circumstances.
@ -913,7 +917,7 @@ Example
The following is a simple unit test using the test client:: The following is a simple unit test using the test client::
import unittest from django.utils import unittest
from django.test.client import Client from django.test.client import Client
class SimpleTest(unittest.TestCase): 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:: This means, instead of instantiating a ``Client`` in each test::
import unittest from django.utils import unittest
from django.test.client import Client from django.test.client import Client
class SimpleTest(unittest.TestCase): class SimpleTest(unittest.TestCase):