From 9854d9497c4d67095d806c40bd54f82c858202fc Mon Sep 17 00:00:00 2001 From: holger krekel Date: Mon, 18 May 2009 18:59:29 +0200 Subject: [PATCH] small documentation refinements --HG-- branch : trunk --- doc/test/features.txt | 2 +- doc/test/funcargs.txt | 4 ++-- doc/test/plugins.txt | 9 +++++++++ 3 files changed, 12 insertions(+), 3 deletions(-) diff --git a/doc/test/features.txt b/doc/test/features.txt index b669df2b1..00442e124 100644 --- a/doc/test/features.txt +++ b/doc/test/features.txt @@ -265,7 +265,7 @@ For example, in order to avoid running some tests on Win32:: 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 ``yield`` callables and their arguments. This is useful for running a diff --git a/doc/test/funcargs.txt b/doc/test/funcargs.txt index 2db765422..0b1631612 100644 --- a/doc/test/funcargs.txt +++ b/doc/test/funcargs.txt @@ -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/ .. _`xUnit style`: xunit_setup.html -.. _`old-style generative tests`: +.. _`old-style generative tests`: features.html#generative-tests .. _`funcarg provider`: @@ -273,7 +273,7 @@ application specific test setup 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 -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. step 1: use and implement a test/app-specific "mysetup" diff --git a/doc/test/plugins.txt b/doc/test/plugins.txt index ac6c9aa3f..b47bce29b 100644 --- a/doc/test/plugins.txt +++ b/doc/test/plugins.txt @@ -53,6 +53,15 @@ py.test loads and configures plugins at tool startup: * by loading all plugins specified via a ``pytest_plugins`` 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 -----------------------------------