Author: adrian
Date: 2007-08-15 00:28:29 -0500 (Wed, 15 Aug 2007)
New Revision: 5890
Modified:
django/trunk/docs/testing.txt
Log:
Removed stray tabs mistakenly added to docs/testing.txt in [5889]
Modified: django/trunk/docs/testing.txt
===================================================================
--- django/trunk/docs/testing.txt 2007-08-15 05:24:18 UTC (rev 5889)
+++ django/trunk/docs/testing.txt 2007-08-15 05:28:29 UTC (rev 5890)
@@ -39,30 +39,30 @@
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::
+ * **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'
+ def my_func(a_list, idx):
"""
- 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
- 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 @@
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 @@
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 @@
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 @@
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 @@
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
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en
-~----------~----~----~----~------~----~------~--~---
