Merge upstream master

1 files changed, 36 insertions, 34 deletions

diff --git a/docs/narr/testing.rst b/docs/narr/testing.rst
index c05ee41ad..354a462d4 100644
--- a/docs/narr/testing.rst
+++ b/docs/narr/testing.rst
@@ -275,7 +275,7 @@ without needing to invoke the actual application configuration implied by its
            
 In the above example, we create a ``MyTest`` test case that inherits from
 :class:`unittest.TestCase`.  If it's in our :app:`Pyramid` application, it will
-be found when ``setup.py test`` is run.  It has two test methods.
+be found when ``py.test`` is run.  It has two test methods.
 
 The first test method, ``test_view_fn_forbidden`` tests the ``view_fn`` when
 the authentication policy forbids the current user the ``edit`` permission. Its
@@ -348,26 +348,6 @@ code's integration with the rest of :app:`Pyramid`.
 
    See also :ref:`including_configuration`
 
-Let's demonstrate this by showing an integration test for a view.
-
-Given the following view definition, which assumes that your application's
-:term:`package` name is ``myproject``, and within that :term:`package` there
-exists a module ``views``, which in turn contains a :term:`view` function named
-``my_view``:
-
-   .. literalinclude:: MyProject/myproject/views.py
-      :linenos:
-      :lines: 1-6
-      :language: python
-
-You'd then create a ``tests`` module within your ``myproject`` package,
-containing the following test code:
-
-   .. literalinclude:: MyProject/myproject/tests.py
-      :linenos:
-      :pyobject: ViewIntegrationTests
-      :language: python
-
 Writing unit tests that use the :class:`~pyramid.config.Configurator` API to
 set up the right "mock" registrations is often preferred to creating
 integration tests.  Unit tests will run faster (because they do less for each
@@ -385,25 +365,47 @@ Functional tests test your literal application.
 
 In Pyramid, functional tests are typically written using the :term:`WebTest`
 package, which provides APIs for invoking HTTP(S) requests to your application.
+We also like ``py.test`` and ``pytest-cov`` to provide simple testing and
+coverage reports.
 
-Regardless of which testing :term:`package` you use, ensure to add a
-``tests_require`` dependency on that package to your application's
-``setup.py`` file:
+Regardless of which testing :term:`package` you use, be sure to add a
+``tests_require`` dependency on that package to your application's ``setup.py``
+file. Using the project ``MyProject`` generated by the starter scaffold as
+described in :doc:`project`, we would insert the following code immediately
+following the ``requires`` block in the file ``MyProject/setup.py``.
 
-   .. literalinclude:: MyProject/setup.py
-      :linenos:
-      :emphasize-lines: 26-28,48
-      :language: python
+.. literalinclude:: MyProject/setup.py
+    :language: python
+    :linenos:
+    :lines: 11-22
+    :lineno-start: 11
+    :emphasize-lines: 8-
+
+Remember to change the dependency.
+
+.. literalinclude:: MyProject/setup.py
+    :language: python
+    :linenos:
+    :lines: 40-44
+    :lineno-start: 40
+    :emphasize-lines: 2-4
+
+As always, whenever you change your dependencies, make sure to run the correct
+``pip install -e`` command.
+
+.. code-block:: bash
+
+    $VENV/bin/pip install -e ".[testing]"
 
-Let us assume your :term:`package` is named ``myproject`` which contains a
-``views`` module, which in turn contains a :term:`view` function ``my_view``
-that returns a HTML body when the root URL is invoked:
+In your ``MyPackage`` project, your :term:`package` is named ``myproject``
+which contains a ``views`` module, which in turn contains a :term:`view`
+function ``my_view`` that returns an HTML body when the root URL is invoked:
 
    .. literalinclude:: MyProject/myproject/views.py
       :linenos:
       :language: python
 
-Then the following example functional test demonstrates invoking the above
+The following example functional test demonstrates invoking the above
 :term:`view`:
 
    .. literalinclude:: MyProject/myproject/tests.py
@@ -414,9 +416,9 @@ Then the following example functional test demonstrates invoking the above
 When this test is run, each test method creates a "real" :term:`WSGI`
 application using the ``main`` function in your ``myproject.__init__`` module,
 using :term:`WebTest` to wrap that WSGI application.  It assigns the result to
-``self.testapp``.  In the test named ``test_root``. The ``TestApp``'s ``GET``
+``self.testapp``.  In the test named ``test_root``, the ``TestApp``'s ``GET``
 method is used to invoke the root URL.  Finally, an assertion is made that the
-returned HTML contains the text ``MyProject``.
+returned HTML contains the text ``Pyramid``.
 
 See the :term:`WebTest` documentation for further information about the methods
 available to a :class:`webtest.app.TestApp` instance.