From 1cb30e690a7ba97db212e7ec9002fd83f950b0bd Mon Sep 17 00:00:00 2001 From: Steve Piercy Date: Sat, 23 Apr 2016 02:45:04 -0700 Subject: Fix all the stinky linkie rot via `make linkcheck SPHINXBUILD=$VENV/bin/sphinx-build`, but don't bother with HISTORY.txt or whatsnew-xx --- docs/narr/project.rst | 40 ++++++++++++++++++++-------------------- 1 file changed, 20 insertions(+), 20 deletions(-) (limited to 'docs/narr/project.rst') diff --git a/docs/narr/project.rst b/docs/narr/project.rst index 81fc9acf4..56247ee33 100644 --- a/docs/narr/project.rst +++ b/docs/narr/project.rst @@ -584,7 +584,7 @@ only (``127.0.0.1``). The sections after ``# logging configuration`` represent Python's standard library :mod:`logging` module configuration for your application. These sections are passed to the `logging module's config file configuration engine -`_ when the +`_ when the ``pserve`` or ``pshell`` commands are executed. The default configuration sends application logging output to the standard error output of your terminal. For more information about logging configuration, see :ref:`logging_chapter`. @@ -628,8 +628,8 @@ setup.py sdist``. Due to the information contained in the default ``MANIFEST.in``, an sdist of your Pyramid project will include ``.txt`` files, ``.ini`` files, ``.rst`` files, graphics files, and template files, as well as ``.py`` files. See -http://docs.python.org/distutils/sourcedist.html#the-manifest-in-template for -more information about the syntax and usage of ``MANIFEST.in``. +https://docs.python.org/2/distutils/sourcedist.html#the-manifest-in-template +for more information about the syntax and usage of ``MANIFEST.in``. Without the presence of a ``MANIFEST.in`` file or without checking your source code into a version control repository, ``setup.py sdist`` places only *Python @@ -647,8 +647,8 @@ files with extensions other than the files named in the project's ``MANIFEST.in`` and you don't make use of a setuptools-compatible version control system, you'll need to edit the ``MANIFEST.in`` file and include the statements necessary to include your new files. See -http://docs.python.org/distutils/sourcedist.html#principle for more information -about how to do this. +https://docs.python.org/2/distutils/sourcedist.html#principle for more +information about how to do this. You can also delete ``MANIFEST.in`` from your project and rely on a setuptools feature which simply causes all files checked into a version control system to @@ -697,21 +697,21 @@ Your application's name can be any string; it is specified in the ``name`` field. The version number is specified in the ``version`` value. A short description is provided in the ``description`` field. The ``long_description`` is conventionally the content of the ``README`` and ``CHANGES`` files appended -together. The ``classifiers`` field is a list of `Trove -`_ classifiers -describing your application. ``author`` and ``author_email`` are text fields -which probably don't need any description. ``url`` is a field that should -point at your application project's URL (if any). ``packages=find_packages()`` -causes all packages within the project to be found when packaging the -application. ``include_package_data`` will include non-Python files when the -application is packaged if those files are checked into version control. -``zip_safe=False`` indicates that this package is not safe to use as a zipped -egg; instead it will always unpack as a directory, which is more convenient. -``install_requires`` indicate that this package depends on the ``pyramid`` -package. ``extras_require`` is a Python dictionary that defines what is -required to be installed for running tests. We examined ``entry_points`` in our -discussion of the ``development.ini`` file; this file defines the ``main`` -entry point that represents our project's application. +together. The ``classifiers`` field is a list of `Trove classifiers +`_ describing your +application. ``author`` and ``author_email`` are text fields which probably +don't need any description. ``url`` is a field that should point at your +application project's URL (if any). ``packages=find_packages()`` causes all +packages within the project to be found when packaging the application. +``include_package_data`` will include non-Python files when the application is +packaged if those files are checked into version control. ``zip_safe=False`` +indicates that this package is not safe to use as a zipped egg; instead it will +always unpack as a directory, which is more convenient. ``install_requires`` +indicates that this package depends on the ``pyramid`` package. +``extras_require`` is a Python dictionary that defines what is required to be +installed for running tests. We examined ``entry_points`` in our discussion of +the ``development.ini`` file; this file defines the ``main`` entry point that +represents our project's application. Usually you only need to think about the contents of the ``setup.py`` file when distributing your application to other people, when adding Python package -- cgit v1.2.3 From 68ba583735aedc6762131af2cf93cf0fdd470fef Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Vincent=20F=C3=A9rotin?= Date: Fri, 6 May 2016 19:45:32 +0200 Subject: doc: Update documentation for using ``py.test [--cov]`` for newly created project with scaffolds. --- docs/narr/project.rst | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) (limited to 'docs/narr/project.rst') diff --git a/docs/narr/project.rst b/docs/narr/project.rst index 56247ee33..8849e9ee7 100644 --- a/docs/narr/project.rst +++ b/docs/narr/project.rst @@ -209,25 +209,29 @@ On UNIX: .. code-block:: bash - $ $VENV/bin/py.test myproject/tests.py -q + $ $VENV/bin/py.test -q On Windows: .. code-block:: doscon - > %VENV%\Scripts\py.test myproject\tests.py -q + > %VENV%\Scripts\py.test -q Here's sample output from a test run on UNIX: .. code-block:: bash - $ $VENV/bin/py.test myproject/tests.py -q + $ $VENV/bin/py.test -q .. 2 passed in 0.47 seconds The tests themselves are found in the ``tests.py`` module in your ``pcreate`` generated project. Within a project generated by the ``starter`` scaffold, -only two sample tests exist. +only two sample tests exist. Previous command is identical to: + +.. code-block:: bash + + $ $VENV/bin/py.test myproject/tests.py -q .. note:: @@ -235,6 +239,14 @@ only two sample tests exist. to a stream of dots. If you don't pass ``-q``, you'll see verbose test result output (which normally isn't very useful). +Alternatively, if you'd like to see test coverage, pass the ``--cov`` option +to ``py.test``: + +.. code-block:: bash + + $ $VENV/bin/py.test -q --cov + + .. index:: single: running an application single: pserve -- cgit v1.2.3 From e09369f02f61f2443f393bcd29fa84e970268b53 Mon Sep 17 00:00:00 2001 From: Steve Piercy Date: Sat, 7 May 2016 00:54:55 -0700 Subject: wordsmith py.test and coverage configuration --- docs/narr/project.rst | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) (limited to 'docs/narr/project.rst') diff --git a/docs/narr/project.rst b/docs/narr/project.rst index 8849e9ee7..a25394151 100644 --- a/docs/narr/project.rst +++ b/docs/narr/project.rst @@ -227,11 +227,7 @@ Here's sample output from a test run on UNIX: The tests themselves are found in the ``tests.py`` module in your ``pcreate`` generated project. Within a project generated by the ``starter`` scaffold, -only two sample tests exist. Previous command is identical to: - -.. code-block:: bash - - $ $VENV/bin/py.test myproject/tests.py -q +only two sample tests exist. .. note:: @@ -244,7 +240,19 @@ to ``py.test``: .. code-block:: bash - $ $VENV/bin/py.test -q --cov + $ $VENV/bin/py.test --cov -q + +Scaffolds include configuration defaults for ``py.test`` and test coverage. +These configuration files are ``pytest.ini`` and ``.coveragerc``, located at +the root of your package. Without these defaults, we would need to specify the +path to the module on which we want to run tests and coverage. + +.. code-block:: bash + + $ $VENV/bin/py.test --cov=myproject myproject/tests.py -q + +.. seealso:: See py.test's documentation for :ref:`pytest:usage` or invoke + ``py.test -h`` to see its full set of options. .. index:: -- cgit v1.2.3 From ea252c3df9cab326a5a5e9a7bdcafae637bd0d47 Mon Sep 17 00:00:00 2001 From: Steve Piercy Date: Sat, 7 May 2016 01:53:23 -0700 Subject: update narr/project.rst with py.test and coverage defaults --- docs/narr/project.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'docs/narr/project.rst') diff --git a/docs/narr/project.rst b/docs/narr/project.rst index a25394151..1ce12a938 100644 --- a/docs/narr/project.rst +++ b/docs/narr/project.rst @@ -929,10 +929,10 @@ The ``tests.py`` module includes unit tests for your application. :linenos: This sample ``tests.py`` file has one unit test and one functional test defined -within it. These tests are executed when you run ``py.test myproject/tests.py --q``. You may add more tests here as you build your application. You are not -required to write tests to use :app:`Pyramid`. This file is simply provided for -convenience and example. +within it. These tests are executed when you run ``py.test -q``. You may add +more tests here as you build your application. You are not required to write +tests to use :app:`Pyramid`. This file is simply provided for convenience and +example. See :ref:`testing_chapter` for more information about writing :app:`Pyramid` unit tests. -- cgit v1.2.3