Prep for b1

Merge a bunch of paper-based docs fixes

Configure logging during bfgshell.

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: