From 3bfda4fa621a771d0d6c16e5db605226fa2a546a Mon Sep 17 00:00:00 2001 From: Adrian Holovaty Date: Wed, 15 Aug 2007 05:28:29 +0000 Subject: [PATCH] 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 --- docs/testing.txt | 98 ++++++++++++++++++++++++------------------------ 1 file changed, 49 insertions(+), 49 deletions(-) diff --git a/docs/testing.txt b/docs/testing.txt index 07b70cf5e5..0bd53f15d7 100644 --- a/docs/testing.txt +++ b/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:: + * **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 @@ 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