Django

Code

Changeset 5890

Show
Ignore:
Timestamp:
08/15/07 00:28:29 (1 year ago)
Author:
adrian
Message:

Removed stray tabs mistakenly added to docs/testing.txt in [5889]

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved
  • django/trunk/docs/testing.txt

    r5889 r5890  
    4040frameworks are: 
    4141 
    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): 
    5347              """ 
    54                           return a_list[idx] 
    55  
    56         * **Unit tests** -- tests that are expressed as methods on a Python class 
    57           that subclasses ``unittest.TestCase``. For example:: 
    58  
    59               import unittest 
     48              >>> a = ['larry', 'curly', 'moe'] 
     49              >>> my_func(a, 0) 
     50              'larry' 
     51              >>> my_func(a, 1) 
     52              'curly' 
     53              """ 
     54              return a_list[idx] 
     55 
     56    * **Unit tests** -- tests that are expressed as methods on a Python class 
     57      that subclasses ``unittest.TestCase``. For example:: 
     58 
     59          import unittest 
    6060 
    6161          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') 
    6666 
    6767You can choose the test framework you like, depending on which syntax you 
     
    9999places: 
    100100 
    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  
    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. 
     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 
     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. 
    109109 
    110110Here is an example model doctest:: 
    111111 
    112        # models.py 
     112    # models.py 
    113113 
    114114    from django.db import models 
     
    161161unit tests in two places: 
    162162 
    163        * The ``models.py`` file. The test runner looks for any subclass of 
    164          ``unittest.TestCase`` in this module. 
    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. 
     163    * The ``models.py`` file. The test runner looks for any subclass of 
     164      ``unittest.TestCase`` in this module. 
     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. 
    169169 
    170170This example ``unittest.TestCase`` subclass is equivalent to the example given 
     
    214214you: 
    215215 
    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!). 
    221221 
    222222      If you're just getting started with testing, using doctests will probably 
    223223      get you started faster. 
    224224 
    225        * The ``unittest`` framework will probably feel very familiar to developers 
     225    * The ``unittest`` framework will probably feel very familiar to developers 
    226226      coming from Java. ``unittest`` is inspired by Java's JUnit, so you'll 
    227227      feel at home with this method if you've used JUnit or any test framework 
    228228      inspired by JUnit. 
    229229 
    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. 
    236236 
    237237Again, remember that you can use both systems side-by-side (even in the same 
     
    252252``myproject.animals`` unit tests alone with this command:: 
    253253 
    254        # ./manage.py test animals 
     254    # ./manage.py test animals 
    255255 
    256256Note that we used ``animals``, not ``myproject.animals``. 
     
    275275prepares itself:: 
    276276 
    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. 
    282282 
    283283This tells you that the test runner is creating a test database -- a blank,