| 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): |
|---|
| 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') |
|---|
| 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. |
|---|
| 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. |
|---|
| 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!). |
|---|
| 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. |
|---|