p53209761
/
test_ok2
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

small documentation refinements 

--HG--
branch : trunk
This commit is contained in:
holger krekel 2009-05-18 18:59:29 +02:00
parent 6bde251d68
commit 9854d9497c
3 changed files with 12 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
doc/test/features.txt
View File

@ -265,7 +265,7 @@ For example, in order to avoid running some tests on Win32::
generative tests: yielding parametrized tests generative tests: yielding parametrized tests
==================================================== ====================================================
**deprecated since 1.0 in favour of `test generators`_** Deprecated since 1.0 in favour of `test generators`_.
*Generative tests* are test methods that are *generator functions* which *Generative tests* are test methods that are *generator functions* which
``yield`` callables and their arguments. This is useful for running a ``yield`` callables and their arguments. This is useful for running a

4
doc/test/funcargs.txt
View File

@ -34,7 +34,7 @@ convenient enough to
.. _`blog post about the monkeypatch funcarg`: http://tetamap.wordpress.com/2009/03/03/monkeypatching-in-unit-tests-done-right/ .. _`blog post about the monkeypatch funcarg`: http://tetamap.wordpress.com/2009/03/03/monkeypatching-in-unit-tests-done-right/
.. _`xUnit style`: xunit_setup.html .. _`xUnit style`: xunit_setup.html
.. _`old-style generative tests`: .. _`old-style generative tests`: features.html#generative-tests
.. _`funcarg provider`: .. _`funcarg provider`:
@ -273,7 +273,7 @@ application specific test setup
Here is a basic useful step-wise example for handling application Here is a basic useful step-wise example for handling application
specific test setup. The goal is to have one place where we have the specific test setup. The goal is to have one place where we have the
glue code for bootstrapping and configuring application objects and allow glue and test support code for bootstrapping and configuring application objects and allow
test modules and test functions to stay ignorant of involved details. test modules and test functions to stay ignorant of involved details.
step 1: use and implement a test/app-specific "mysetup" step 1: use and implement a test/app-specific "mysetup"

9
doc/test/plugins.txt
View File

@ -53,6 +53,15 @@ py.test loads and configures plugins at tool startup:
* by loading all plugins specified via a ``pytest_plugins`` * by loading all plugins specified via a ``pytest_plugins``
variable in ``conftest.py`` files or test modules. variable in ``conftest.py`` files or test modules.
Specifying a plugin in a test module or ``conftest.py`` will
only lead to activitation when ``py.test`` actually sees the
directory and the file during the collection process. This is
already after command line parsing and there is no try to do
a "pre-scan of all subdirs" as this would mean a potentially
very large delay. As long as you don't add command line options this detail
does not need to worry you.
example: ensure a plugin is loaded example: ensure a plugin is loaded
----------------------------------- -----------------------------------