[Python-checkins] distutils2: updated docs

tarek.ziade python-checkins at python.org
Sun Sep 19 10:20:22 CEST 2010


tarek.ziade pushed 4d66dae7c4ae to distutils2:

http://hg.python.org/distutils2/rev/4d66dae7c4ae
changeset:   619:4d66dae7c4ae
user:        Konrad Delong <konryd at gmail.com>
date:        Fri Aug 13 16:51:43 2010 +0200
summary:     updated docs
files:       docs/source/distutils/newcommands.rst

diff --git a/docs/source/distutils/newcommands.rst b/docs/source/distutils/newcommands.rst
--- a/docs/source/distutils/newcommands.rst
+++ b/docs/source/distutils/newcommands.rst
@@ -12,47 +12,27 @@
 When doing test-driven development, or running automated builds that need
 testing before they are deployed for downloading or use, it's often useful
 to be able to run a project's unit tests without actually deploying the project
-anywhere, even using the ``develop`` command.  The ``test`` command runs a
+anywhere.  The ``test`` command runs
 project's unit tests without actually deploying it, by temporarily putting the
-project's source on ``sys.path``, after first running ``build_ext -i`` and
-``egg_info`` to ensure that any C extensions and project metadata are
-up-to-date.
+project's source on ``sys.path``, after first running ``build_ext -i`` 
+to ensure that any C extensions are built.
 
-To use this command, your project's tests must be wrapped in a ``unittest``
-test suite by either a function, a ``TestCase`` class or method, or a module
-or package containing ``TestCase`` classes.  If the named suite is a module,
-and the module has an ``additional_tests()`` function, it is called and the
-result (which must be a ``unittest.TestSuite``) is added to the tests to be
-run.  If the named suite is a package, any submodules and subpackages are
-recursively added to the overall test suite.  (Note: if your project specifies
-a ``test_loader``, the rules for processing the chosen ``test_suite`` may
-differ; see the `test_loader`_ documentation for more details.)
+You can use this command in one of two ways: either by specifying a
+unittest-compatible test suite for your project (or any callable that returns
+it) or by passing a test runner function that will run your tests and display
+results in the console. Both options: ``suite`` and ``runner`` accept dotted
+names that will be resolved into actual objects.
 
-Note that many test systems including ``doctest`` support wrapping their
-non-``unittest`` tests in ``TestSuite`` objects.  So, if you are using a test
-package that does not support this, we suggest you encourage its developers to
-implement test suite support, as this is a convenient and standard way to
-aggregate a collection of tests to be run under a common test harness.
-
-By default, tests will be run in the "verbose" mode of the ``unittest``
-package's text test runner, but you can get the "quiet" mode (just dots) if
-you supply the ``-q`` or ``--quiet`` option, either as a global option to
-the setup script (for example ``setup.py -q test``) or as an option for the ``test``
-command itself (for example ``setup.py test -q``).  There is one other option
-available:
-
-``--test-suite=NAME, -s NAME``
+``--suite=NAME, -s NAME``
     Specify the test suite (or module, class, or method) to be run
     (for example ``some_module.test_suite``).  The default for this option can be
-    set by giving a ``test_suite`` argument to the ``setup()`` function, for example::
+    set by in your ``setup.cfg`` file. 
 
-        setup(
-            # ...
-            test_suite = "my_package.tests.test_all"
-        )
+        [test]
+            suite = my_package.tests.test_all
 
-    If you did not set a ``test_suite`` in your ``setup()`` call, and do not
-    provide a ``--test-suite`` option, an error will occur.
+``--runner=NAME, -r NAME``
+    Specify the test runner to be called. 
 
 
 ``upload`` - Upload source and/or binary distributions to PyPI

--
Repository URL: http://hg.python.org/distutils2


More information about the Python-checkins mailing list