mirror of https://github.com/django/django.git
Removed stray tabs mistakenly added to docs/testing.txt in [5889]
git-svn-id: http://code.djangoproject.com/svn/django/trunk@5890 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
parent
1ba9012d87
commit
3bfda4fa62
|
@ -39,30 +39,30 @@ There are two primary ways to write tests with Django, corresponding to the
|
||||||
two test frameworks that ship in the Python standard library. The two
|
two test frameworks that ship in the Python standard library. The two
|
||||||
frameworks are:
|
frameworks are:
|
||||||
|
|
||||||
* **Doctests** -- tests that are embedded in your functions' docstrings and
|
* **Doctests** -- tests that are embedded in your functions' docstrings and
|
||||||
are written in a way that emulates a session of the Python interactive
|
are written in a way that emulates a session of the Python interactive
|
||||||
interpreter. For example::
|
interpreter. For example::
|
||||||
|
|
||||||
def my_func(a_list, idx):
|
def my_func(a_list, idx):
|
||||||
"""
|
|
||||||
>>> a = ['larry', 'curly', 'moe']
|
|
||||||
>>> my_func(a, 0)
|
|
||||||
'larry'
|
|
||||||
>>> my_func(a, 1)
|
|
||||||
'curly'
|
|
||||||
"""
|
"""
|
||||||
return a_list[idx]
|
>>> a = ['larry', 'curly', 'moe']
|
||||||
|
>>> my_func(a, 0)
|
||||||
|
'larry'
|
||||||
|
>>> my_func(a, 1)
|
||||||
|
'curly'
|
||||||
|
"""
|
||||||
|
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 ``unittest.TestCase``. For example::
|
||||||
|
|
||||||
import unittest
|
import unittest
|
||||||
|
|
||||||
class MyFuncTestCase(unittest.TestCase)
|
class MyFuncTestCase(unittest.TestCase)
|
||||||
def testBasic(self):
|
def testBasic(self):
|
||||||
a = ['larry', 'curly', 'moe']
|
a = ['larry', 'curly', 'moe']
|
||||||
self.assertEquals(my_func(a, 0), 'larry')
|
self.assertEquals(my_func(a, 0), 'larry')
|
||||||
self.assertEquals(my_func(a, 1), 'curly')
|
self.assertEquals(my_func(a, 1), 'curly')
|
||||||
|
|
||||||
You can choose the test framework you like, depending on which syntax you
|
You can choose the test framework you like, depending on which syntax you
|
||||||
prefer, or you can mix and match, using one framework for some of your code and
|
prefer, or you can mix and match, using one framework for some of your code and
|
||||||
|
@ -98,18 +98,18 @@ read Python's official documentation for the details.
|
||||||
For a given Django application, the test runner looks for doctests in two
|
For a given Django application, the test runner looks for doctests in two
|
||||||
places:
|
places:
|
||||||
|
|
||||||
* The ``models.py`` file. You can define module-level doctests and/or a
|
* The ``models.py`` file. You can define module-level doctests and/or a
|
||||||
doctest for individual models. It's common practice to put
|
doctest for individual models. It's common practice to put
|
||||||
application-level doctests in the module docstring and model-level
|
application-level doctests in the module docstring and model-level
|
||||||
doctests in the model docstrings.
|
doctests in the model docstrings.
|
||||||
|
|
||||||
* A file called ``tests.py`` in the application directory -- i.e., the
|
* A file called ``tests.py`` in the application directory -- i.e., the
|
||||||
directory that holds ``models.py``. This file is a hook for any and all
|
directory that holds ``models.py``. This file is a hook for any and all
|
||||||
doctests you want to write that aren't necessarily related to models.
|
doctests you want to write that aren't necessarily related to models.
|
||||||
|
|
||||||
Here is an example model doctest::
|
Here is an example model doctest::
|
||||||
|
|
||||||
# models.py
|
# models.py
|
||||||
|
|
||||||
from django.db import models
|
from django.db import models
|
||||||
|
|
||||||
|
@ -160,12 +160,12 @@ approach.
|
||||||
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:
|
||||||
|
|
||||||
* The ``models.py`` file. The test runner looks for any subclass of
|
* The ``models.py`` file. The test runner looks for any subclass of
|
||||||
``unittest.TestCase`` in this module.
|
``unittest.TestCase`` in this module.
|
||||||
|
|
||||||
* A file called ``tests.py`` in the application directory -- i.e., the
|
* A file called ``tests.py`` in the application directory -- i.e., the
|
||||||
directory that holds ``models.py``. Again, the test runner looks for any
|
directory that holds ``models.py``. Again, the test runner looks for any
|
||||||
subclass of ``unittest.TestCase`` in this module.
|
subclass of ``unittest.TestCase`` in this module.
|
||||||
|
|
||||||
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::
|
||||||
|
@ -213,26 +213,26 @@ For developers new to testing, however, this choice can seem confusing. Here,
|
||||||
then, are a few key differences to help you decide which approach is right for
|
then, are a few key differences to help you decide which approach is right for
|
||||||
you:
|
you:
|
||||||
|
|
||||||
* If you've been using Python for a while, ``doctest`` will probably feel
|
* If you've been using Python for a while, ``doctest`` will probably feel
|
||||||
more "pythonic". It's designed to make writing tests as easy as possible,
|
more "pythonic". It's designed to make writing tests as easy as possible,
|
||||||
so it requires no overhead of writing classes or methods. You simply put
|
so it requires no overhead of writing classes or methods. You simply put
|
||||||
tests in docstrings. This has the added advantage of serving as
|
tests in docstrings. This has the added advantage of serving as
|
||||||
documentation (and correct documentation, at that!).
|
documentation (and correct documentation, at that!).
|
||||||
|
|
||||||
If you're just getting started with testing, using doctests will probably
|
If you're just getting started with testing, using doctests will probably
|
||||||
get you started faster.
|
get you started faster.
|
||||||
|
|
||||||
* The ``unittest`` framework will probably feel very familiar to developers
|
* The ``unittest`` framework will probably feel very familiar to developers
|
||||||
coming from Java. ``unittest`` is inspired by Java's JUnit, so you'll
|
coming from Java. ``unittest`` is inspired by Java's JUnit, so you'll
|
||||||
feel at home with this method if you've used JUnit or any test framework
|
feel at home with this method if you've used JUnit or any test framework
|
||||||
inspired by JUnit.
|
inspired by JUnit.
|
||||||
|
|
||||||
* If you need to write a bunch of tests that share similar code, then
|
* If you need to write a bunch of tests that share similar code, then
|
||||||
you'll appreciate the ``unittest`` framework's organization around
|
you'll appreciate the ``unittest`` framework's organization around
|
||||||
classes and methods. This makes it easy to abstract common tasks into
|
classes and methods. This makes it easy to abstract common tasks into
|
||||||
common methods. The framework also supports explicit setup and/or cleanup
|
common methods. The framework also supports explicit setup and/or cleanup
|
||||||
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.
|
||||||
|
|
||||||
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
|
||||||
|
@ -251,7 +251,7 @@ application name to the command line. For example, if your ``INSTALLED_APPS``
|
||||||
contains ``'myproject.polls'`` and ``'myproject.animals'``, you can run the
|
contains ``'myproject.polls'`` and ``'myproject.animals'``, you can run the
|
||||||
``myproject.animals`` unit tests alone with this command::
|
``myproject.animals`` unit tests alone with this command::
|
||||||
|
|
||||||
# ./manage.py test animals
|
# ./manage.py test animals
|
||||||
|
|
||||||
Note that we used ``animals``, not ``myproject.animals``.
|
Note that we used ``animals``, not ``myproject.animals``.
|
||||||
|
|
||||||
|
@ -274,11 +274,11 @@ Understanding the test output
|
||||||
When you run your tests, you'll see a number of messages as the test runner
|
When you run your tests, you'll see a number of messages as the test runner
|
||||||
prepares itself::
|
prepares itself::
|
||||||
|
|
||||||
Creating test database...
|
Creating test database...
|
||||||
Creating table myapp_animal
|
Creating table myapp_animal
|
||||||
Creating table myapp_mineral
|
Creating table myapp_mineral
|
||||||
Loading 'initial_data' fixtures...
|
Loading 'initial_data' fixtures...
|
||||||
No fixtures found.
|
No fixtures found.
|
||||||
|
|
||||||
This tells you that the test runner is creating a test database -- a blank,
|
This tells you that the test runner is creating a test database -- a blank,
|
||||||
from-scratch database that it will use for any tests that happen to require a
|
from-scratch database that it will use for any tests that happen to require a
|
||||||
|
|
Loading…
Reference in New Issue