diff options
Diffstat (limited to 'docs/narr/unittesting.rst')
| -rw-r--r-- | docs/narr/unittesting.rst | 10 |
1 files changed, 5 insertions, 5 deletions
diff --git a/docs/narr/unittesting.rst b/docs/narr/unittesting.rst index 9e36ea051..a13f90952 100644 --- a/docs/narr/unittesting.rst +++ b/docs/narr/unittesting.rst @@ -17,7 +17,7 @@ the "unit under test". If you write a unit test that aims to verify the result of a particular codepath through a Python function, you need only be concerned about testing the code that *lives in the function body itself*. If the function accepts a parameter that -represents a complex application "domain object" (such a a model, a +represents a complex application "domain object" (such as a model, a database connection, or an SMTP server), the argument provided to this function during a unit test *need not be* and likely *should not be* a "real" implementation object. For example, although a particular @@ -58,8 +58,8 @@ useful when your code calls into :mod:`repoze.bfg` -related framework functions. .. index:: - pair: test; setup - pair: test; tear down + single: test setup + single: test tear down single: unittest .. _test_setup_and_teardown: @@ -164,7 +164,7 @@ anything if the application you're testing does not call any .. index:: single: repoze.bfg.testing - pair: Configurator; testing + single: Configurator testing API Using the ``Configurator`` and ``repoze.bfg.testing`` APIs in Unit Tests ------------------------------------------------------------------------ @@ -299,7 +299,7 @@ See also the various methods of the :term:`Configurator` documented in :ref:`configuration_module` that begin with the ``testing_`` prefix. .. index:: - pair: creating; integration tests + single: integration tests .. _integration_tests: |
