summaryrefslogtreecommitdiff
path: root/docs/narr/testing.rst
diff options
context:
space:
mode:
authorChris McDonough <chrism@plope.com>2016-02-07 16:34:46 -0500
committerChris McDonough <chrism@plope.com>2016-02-07 16:34:46 -0500
commitdf7a123a847e2243f38688c033f06200382ba139 (patch)
treecc8e032c2a85d9fee45e68f7f3501046c8bec8ed /docs/narr/testing.rst
parent5cd91621668807f9b66811fe57a04fba96e7458a (diff)
parented04017d5a8e82db2e46412f841c55d83ef062b0 (diff)
downloadpyramid-df7a123a847e2243f38688c033f06200382ba139.tar.gz
pyramid-df7a123a847e2243f38688c033f06200382ba139.tar.bz2
pyramid-df7a123a847e2243f38688c033f06200382ba139.zip
Merge branch 'master' of github.com:Pylons/pyramid
Diffstat (limited to 'docs/narr/testing.rst')
-rw-r--r--docs/narr/testing.rst73
1 files changed, 42 insertions, 31 deletions
diff --git a/docs/narr/testing.rst b/docs/narr/testing.rst
index c05ee41ad..a3f62058b 100644
--- a/docs/narr/testing.rst
+++ b/docs/narr/testing.rst
@@ -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
@@ -388,22 +368,53 @@ package, which provides APIs for invoking HTTP(S) requests to your application.
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:
+``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
+.. code-block:: ini
+ :linenos:
+ :lineno-start: 11
+ :emphasize-lines: 8-
+
+ requires = [
+ 'pyramid',
+ 'pyramid_chameleon',
+ 'pyramid_debugtoolbar',
+ 'waitress',
+ ]
+
+ test_requires = [
+ 'webtest',
+ ]
+
+Remember to change the dependency.
+
+.. code-block:: ini
+ :linenos:
+ :lineno-start: 39
+ :emphasize-lines: 2
+
+ install_requires=requires,
+ tests_require=test_requires,
+ test_suite="myproject",
+
+As always, whenever you change your dependencies, make sure to run the
+following command.
+
+.. code-block:: bash
+
+ $VENV/bin/python setup.py develop
-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 +425,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.