1
0
mirror of https://github.com/django/django.git synced 2025-07-04 17:59: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!
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 File

@ -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):