Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

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
  • Loading branch information...
commit 3bfda4fa621a771d0d6c16e5db605226fa2a546a 1 parent 1ba9012
@adrianholovaty adrianholovaty authored
Showing with 50 additions and 50 deletions.
  1. +50 −50 docs/testing.txt
View
100 docs/testing.txt
@@ -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
frameworks are:
- * **Doctests** -- tests that are embedded in your functions' docstrings and
- are written in a way that emulates a session of the Python interactive
- interpreter. For example::
-
- def my_func(a_list, idx):
- """
- >>> a = ['larry', 'curly', 'moe']
- >>> my_func(a, 0)
- 'larry'
- >>> my_func(a, 1)
- 'curly'
+ * **Doctests** -- tests that are embedded in your functions' docstrings and
+ are written in a way that emulates a session of the Python interactive
+ interpreter. For example::
+
+ def my_func(a_list, idx):
+ """
+ >>> a = ['larry', 'curly', 'moe']
+ >>> my_func(a, 0)
+ 'larry'
+ >>> my_func(a, 1)
+ 'curly'
"""
- return a_list[idx]
+ return a_list[idx]
- * **Unit tests** -- tests that are expressed as methods on a Python class
- that subclasses ``unittest.TestCase``. For example::
+ * **Unit tests** -- tests that are expressed as methods on a Python class
+ that subclasses ``unittest.TestCase``. For example::
- import unittest
+ import unittest
class MyFuncTestCase(unittest.TestCase)
- def testBasic(self):
- a = ['larry', 'curly', 'moe']
- self.assertEquals(my_func(a, 0), 'larry')
- self.assertEquals(my_func(a, 1), 'curly')
+ def testBasic(self):
+ a = ['larry', 'curly', 'moe']
+ self.assertEquals(my_func(a, 0), 'larry')
+ self.assertEquals(my_func(a, 1), 'curly')
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
@@ -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
places:
- * The ``models.py`` file. You can define module-level doctests and/or a
- doctest for individual models. It's common practice to put
- application-level doctests in the module docstring and model-level
- doctests in the model docstrings.
+ * The ``models.py`` file. You can define module-level doctests and/or a
+ doctest for individual models. It's common practice to put
+ application-level doctests in the module docstring and model-level
+ doctests in the model docstrings.
- * 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
- doctests you want to write that aren't necessarily related to models.
+ * 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
+ doctests you want to write that aren't necessarily related to models.
Here is an example model doctest::
- # models.py
+ # models.py
from django.db import models
@@ -160,12 +160,12 @@ approach.
As with doctests, for a given Django application, the test runner looks for
unit tests in two places:
- * The ``models.py`` file. The test runner looks for any subclass of
- ``unittest.TestCase`` in this module.
+ * The ``models.py`` file. The test runner looks for any subclass of
+ ``unittest.TestCase`` in this module.
- * A file called ``tests.py`` in the application directory -- i.e., the
- directory that holds ``models.py``. Again, the test runner looks for any
- subclass of ``unittest.TestCase`` in this module.
+ * A file called ``tests.py`` in the application directory -- i.e., the
+ directory that holds ``models.py``. Again, the test runner looks for any
+ subclass of ``unittest.TestCase`` in this module.
This example ``unittest.TestCase`` subclass is equivalent to the example given
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
you:
- * 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,
- so it requires no overhead of writing classes or methods. You simply put
- tests in docstrings. This has the added advantage of serving as
- documentation (and correct documentation, at that!).
+ * 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,
+ so it requires no overhead of writing classes or methods. You simply put
+ tests in docstrings. This has the added advantage of serving as
+ documentation (and correct documentation, at that!).
If you're just getting started with testing, using doctests will probably
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
feel at home with this method if you've used JUnit or any test framework
inspired by JUnit.
- * If you need to write a bunch of tests that share similar code, then
- you'll appreciate the ``unittest`` framework's organization around
- classes and methods. This makes it easy to abstract common tasks into
- common methods. The framework also supports explicit setup and/or cleanup
- routines, which give you a high level of control over the environment
- in which your test cases are run.
+ * If you need to write a bunch of tests that share similar code, then
+ you'll appreciate the ``unittest`` framework's organization around
+ classes and methods. This makes it easy to abstract common tasks into
+ common methods. The framework also supports explicit setup and/or cleanup
+ routines, which give you a high level of control over the environment
+ in which your test cases are run.
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
@@ -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
``myproject.animals`` unit tests alone with this command::
- # ./manage.py test animals
+ # ./manage.py test 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
prepares itself::
- Creating test database...
- Creating table myapp_animal
- Creating table myapp_mineral
- Loading 'initial_data' fixtures...
- No fixtures found.
+ Creating test database...
+ Creating table myapp_animal
+ Creating table myapp_mineral
+ Loading 'initial_data' fixtures...
+ No fixtures found.
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
Please sign in to comment.
Something went wrong with that request. Please try again.