Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse code

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
Adrian Holovaty authored August 15, 2007

Showing 1 changed file with 50 additions and 50 deletions. Show diff stats Hide diff stats

  1. 100  docs/testing.txt
100  docs/testing.txt
@@ -39,30 +39,30 @@ There are two primary ways to write tests with Django, corresponding to the
39 39
 two test frameworks that ship in the Python standard library. The two
40 40
 frameworks are:
41 41
 
42  
-	* **Doctests** -- tests that are embedded in your functions' docstrings and
43  
-	  are written in a way that emulates a session of the Python interactive
44  
-	  interpreter. For example::
45  
-
46  
-	      def my_func(a_list, idx):
47  
-		      """
48  
-		      >>> a = ['larry', 'curly', 'moe']
49  
-		      >>> my_func(a, 0)
50  
-			  'larry'
51  
-			  >>> my_func(a, 1)
52  
-			  'curly'
  42
+    * **Doctests** -- tests that are embedded in your functions' docstrings and
  43
+      are written in a way that emulates a session of the Python interactive
  44
+      interpreter. For example::
  45
+
  46
+          def my_func(a_list, idx):
  47
+              """
  48
+              >>> a = ['larry', 'curly', 'moe']
  49
+              >>> my_func(a, 0)
  50
+              'larry'
  51
+              >>> my_func(a, 1)
  52
+              'curly'
53 53
               """
54  
-			  return a_list[idx]
  54
+              return a_list[idx]
55 55
 
56  
-	* **Unit tests** -- tests that are expressed as methods on a Python class
57  
-	  that subclasses ``unittest.TestCase``. For example::
  56
+    * **Unit tests** -- tests that are expressed as methods on a Python class
  57
+      that subclasses ``unittest.TestCase``. For example::
58 58
 
59  
-	      import unittest
  59
+          import unittest
60 60
 
61 61
           class MyFuncTestCase(unittest.TestCase)
62  
-		      def testBasic(self):
63  
-		          a = ['larry', 'curly', 'moe']
64  
-		          self.assertEquals(my_func(a, 0), 'larry')
65  
-			      self.assertEquals(my_func(a, 1), 'curly')
  62
+              def testBasic(self):
  63
+                  a = ['larry', 'curly', 'moe']
  64
+                  self.assertEquals(my_func(a, 0), 'larry')
  65
+                  self.assertEquals(my_func(a, 1), 'curly')
66 66
 
67 67
 You can choose the test framework you like, depending on which syntax you
68 68
 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.
98 98
 For a given Django application, the test runner looks for doctests in two
99 99
 places:
100 100
 
101  
-	* The ``models.py`` file. You can define module-level doctests and/or a
102  
-	  doctest for individual models. It's common practice to put
103  
-	  application-level doctests in the module docstring and model-level
104  
-	  doctests in the model docstrings.
  101
+    * The ``models.py`` file. You can define module-level doctests and/or a
  102
+      doctest for individual models. It's common practice to put
  103
+      application-level doctests in the module docstring and model-level
  104
+      doctests in the model docstrings.
105 105
 
106  
-	* A file called ``tests.py`` in the application directory -- i.e., the
107  
-	  directory that holds ``models.py``. This file is a hook for any and all
108  
-	  doctests you want to write that aren't necessarily related to models.
  106
+    * A file called ``tests.py`` in the application directory -- i.e., the
  107
+      directory that holds ``models.py``. This file is a hook for any and all
  108
+      doctests you want to write that aren't necessarily related to models.
109 109
 
110 110
 Here is an example model doctest::
111 111
 
112  
-	# models.py
  112
+    # models.py
113 113
 
114 114
     from django.db import models
115 115
 
@@ -160,12 +160,12 @@ approach.
160 160
 As with doctests, for a given Django application, the test runner looks for
161 161
 unit tests in two places:
162 162
 
163  
-	* The ``models.py`` file. The test runner looks for any subclass of
164  
-	  ``unittest.TestCase`` in this module.
  163
+    * The ``models.py`` file. The test runner looks for any subclass of
  164
+      ``unittest.TestCase`` in this module.
165 165
 
166  
-	* A file called ``tests.py`` in the application directory -- i.e., the
167  
-	  directory that holds ``models.py``. Again, the test runner looks for any
168  
-	  subclass of ``unittest.TestCase`` in this module.
  166
+    * A file called ``tests.py`` in the application directory -- i.e., the
  167
+      directory that holds ``models.py``. Again, the test runner looks for any
  168
+      subclass of ``unittest.TestCase`` in this module.
169 169
 
170 170
 This example ``unittest.TestCase`` subclass is equivalent to the example given
171 171
 in the doctest section above::
@@ -213,26 +213,26 @@ For developers new to testing, however, this choice can seem confusing. Here,
213 213
 then, are a few key differences to help you decide which approach is right for
214 214
 you:
215 215
 
216  
-	* If you've been using Python for a while, ``doctest`` will probably feel
217  
-	  more "pythonic". It's designed to make writing tests as easy as possible,
218  
-	  so it requires no overhead of writing classes or methods. You simply put
219  
-	  tests in docstrings. This has the added advantage of serving as
220  
-	  documentation (and correct documentation, at that!).
  216
+   * If you've been using Python for a while, ``doctest`` will probably feel
  217
+      more "pythonic". It's designed to make writing tests as easy as possible,
  218
+      so it requires no overhead of writing classes or methods. You simply put
  219
+      tests in docstrings. This has the added advantage of serving as
  220
+      documentation (and correct documentation, at that!).
221 221
 
222 222
       If you're just getting started with testing, using doctests will probably
223 223
       get you started faster.
224 224
 
225  
-	* The ``unittest`` framework will probably feel very familiar to developers
  225
+    * The ``unittest`` framework will probably feel very familiar to developers
226 226
       coming from Java. ``unittest`` is inspired by Java's JUnit, so you'll
227 227
       feel at home with this method if you've used JUnit or any test framework
228 228
       inspired by JUnit.
229 229
 
230  
-	* If you need to write a bunch of tests that share similar code, then
231  
-	  you'll appreciate the ``unittest`` framework's organization around
232  
-	  classes and methods. This makes it easy to abstract common tasks into
233  
-	  common methods. The framework also supports explicit setup and/or cleanup
234  
-	  routines, which give you a high level of control over the environment
235  
-	  in which your test cases are run.
  230
+    * If you need to write a bunch of tests that share similar code, then
  231
+      you'll appreciate the ``unittest`` framework's organization around
  232
+      classes and methods. This makes it easy to abstract common tasks into
  233
+      common methods. The framework also supports explicit setup and/or cleanup
  234
+      routines, which give you a high level of control over the environment
  235
+      in which your test cases are run.
236 236
 
237 237
 Again, remember that you can use both systems side-by-side (even in the same
238 238
 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``
251 251
 contains ``'myproject.polls'`` and ``'myproject.animals'``, you can run the
252 252
 ``myproject.animals`` unit tests alone with this command::
253 253
 
254  
-	# ./manage.py test animals
  254
+    # ./manage.py test animals
255 255
 
256 256
 Note that we used ``animals``, not ``myproject.animals``.
257 257
 
@@ -274,11 +274,11 @@ Understanding the test output
274 274
 When you run your tests, you'll see a number of messages as the test runner
275 275
 prepares itself::
276 276
 
277  
-	Creating test database...
278  
-	Creating table myapp_animal
279  
-	Creating table myapp_mineral
280  
-	Loading 'initial_data' fixtures...
281  
-	No fixtures found.
  277
+    Creating test database...
  278
+    Creating table myapp_animal
  279
+    Creating table myapp_mineral
  280
+    Loading 'initial_data' fixtures...
  281
+    No fixtures found.
282 282
 
283 283
 This tells you that the test runner is creating a test database -- a blank,
284 284
 from-scratch database that it will use for any tests that happen to require a

0 notes on commit 3bfda4f

Please sign in to comment.
Something went wrong with that request. Please try again.