major refinements to documentation and examples
--HG-- branch : trunk
This commit is contained in:
		
							parent
							
								
									9925ac883e
								
							
						
					
					
						commit
						2e4391d28e
					
				| 
						 | 
				
			
			@ -13,8 +13,6 @@ py.test reference documentation
 | 
			
		|||
   skipping.txt
 | 
			
		||||
   mark.txt
 | 
			
		||||
   recwarn.txt
 | 
			
		||||
   reporting.txt
 | 
			
		||||
   debugging.txt
 | 
			
		||||
   doctest.txt
 | 
			
		||||
   unittest.txt
 | 
			
		||||
   
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -0,0 +1,58 @@
 | 
			
		|||
.. _`setuptools installation`: http://pypi.python.org/pypi/setuptools
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
Basic usage
 | 
			
		||||
==================
 | 
			
		||||
 | 
			
		||||
We assume you have done an :ref:`install` like this::
 | 
			
		||||
 | 
			
		||||
    easy_install -U pytest # or
 | 
			
		||||
    pip install -U pytest
 | 
			
		||||
 | 
			
		||||
Ensure that this installed the ``py.test`` script::
 | 
			
		||||
 | 
			
		||||
    py.test --version
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
Writing a first test
 | 
			
		||||
------------------------------
 | 
			
		||||
 | 
			
		||||
Let's create a small file with the following content::
 | 
			
		||||
 | 
			
		||||
    # content of test_sample.py
 | 
			
		||||
    def func(x):
 | 
			
		||||
        return x + 1
 | 
			
		||||
    def test_answer():
 | 
			
		||||
        assert func(3) == 5
 | 
			
		||||
 | 
			
		||||
That's it.  Now you can already execute the test function::
 | 
			
		||||
 | 
			
		||||
    $ py.test test_sample.py
 | 
			
		||||
    =========================== test session starts ============================
 | 
			
		||||
    platform linux2 -- Python 2.6.5 -- pytest-2.0.0dev0
 | 
			
		||||
    test path 1: test_sample.py
 | 
			
		||||
    
 | 
			
		||||
    test_sample.py F
 | 
			
		||||
    
 | 
			
		||||
    ================================= FAILURES =================================
 | 
			
		||||
    _______________________________ test_answer ________________________________
 | 
			
		||||
    
 | 
			
		||||
        def test_answer():
 | 
			
		||||
    >       assert func(3) == 5
 | 
			
		||||
    E       assert 4 == 5
 | 
			
		||||
    E        +  where 4 = func(3)
 | 
			
		||||
    
 | 
			
		||||
    test_sample.py:4: AssertionError
 | 
			
		||||
    ========================= 1 failed in 0.02 seconds =========================
 | 
			
		||||
 | 
			
		||||
We got a failure because our little ``func(3)`` call did not return ``5``.
 | 
			
		||||
A few notes on this little test invocation:
 | 
			
		||||
 | 
			
		||||
* ``test_answer`` was identified as a test function because of the
 | 
			
		||||
  ``test_`` prefix,
 | 
			
		||||
 | 
			
		||||
*  we conveniently used the standard `assert statement`_ and the failure
 | 
			
		||||
   report shows us the intermediate values.
 | 
			
		||||
 | 
			
		||||
.. _`assert statement`: http://docs.python.org/reference/simple_stmts.html#the-assert-statement
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			@ -0,0 +1,111 @@
 | 
			
		|||
 | 
			
		||||
Using the interactive command line
 | 
			
		||||
===============================================
 | 
			
		||||
 | 
			
		||||
Getting help on version, option names, environment vars
 | 
			
		||||
-----------------------------------------------------------
 | 
			
		||||
 | 
			
		||||
::
 | 
			
		||||
 | 
			
		||||
    py.test --version   # shows where pytest was imported from
 | 
			
		||||
    py.test --funcargs  # show available builtin function arguments
 | 
			
		||||
    py.test --help-config # show configuration values
 | 
			
		||||
    
 | 
			
		||||
    py.test -h | --help # show help
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
Stopping after the first (or N) failures
 | 
			
		||||
---------------------------------------------------
 | 
			
		||||
 | 
			
		||||
To stop the testing process after the first (N) failures::
 | 
			
		||||
 | 
			
		||||
    py.test -x            # stop after first failure
 | 
			
		||||
    py.test -maxfail=2    # stop after two failures
 | 
			
		||||
 | 
			
		||||
Modifying Python traceback printing
 | 
			
		||||
----------------------------------------------
 | 
			
		||||
 | 
			
		||||
Examples for modifying traceback printing::
 | 
			
		||||
 | 
			
		||||
    py.test --showlocals # show local variables in tracebacks
 | 
			
		||||
    py.test -l           # show local variables (shortcut)
 | 
			
		||||
 | 
			
		||||
    py.test --tb=long    # the default informative traceback formatting
 | 
			
		||||
    py.test --tb=native  # the Python standard library formatting
 | 
			
		||||
    py.test --tb=short   # a shorter traceback format
 | 
			
		||||
    py.test --tb=line    # only one line per failure
 | 
			
		||||
 | 
			
		||||
Dropping to PDB (Python Debugger) on failures
 | 
			
		||||
----------------------------------------------
 | 
			
		||||
 | 
			
		||||
.. _PDB: http://docs.python.org/library/pdb.html
 | 
			
		||||
 | 
			
		||||
Python comes with a builtin Python debugger called PDB_.  ``py.test`` 
 | 
			
		||||
allows to drop into the PDB prompt via a command line option::
 | 
			
		||||
 | 
			
		||||
    py.test --pdb
 | 
			
		||||
 | 
			
		||||
This will invoke the Python debugger on every failure.  Often you might
 | 
			
		||||
only want to do this for the first failing test to understand a certain
 | 
			
		||||
failure situation::
 | 
			
		||||
 | 
			
		||||
    py.test -x --pdb   # drop to PDB on first failure, then end test session
 | 
			
		||||
    py.test --pdb --maxfail=3  # drop to PDB for the first three failures
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
Setting a breakpoint / aka ``set_trace()``
 | 
			
		||||
----------------------------------------------------
 | 
			
		||||
 | 
			
		||||
If you want to set a breakpoint and enter the ``pdb.set_trace()`` you
 | 
			
		||||
can use a helper::
 | 
			
		||||
 | 
			
		||||
    def test_function():
 | 
			
		||||
        ...
 | 
			
		||||
        py.test.set_trace()    # invoke PDB debugger and tracing
 | 
			
		||||
 | 
			
		||||
.. versionadded: 2.0.0
 | 
			
		||||
 | 
			
		||||
In previous versions you could only enter PDB tracing if
 | 
			
		||||
you :ref:`disable capturing`.
 | 
			
		||||
 | 
			
		||||
creating JUnitXML format files
 | 
			
		||||
----------------------------------------------------
 | 
			
		||||
 | 
			
		||||
To create result files which can be read by Hudson_ or other Continous
 | 
			
		||||
integration servers, use this invocation::
 | 
			
		||||
 | 
			
		||||
    py.test --junitxml=path
 | 
			
		||||
 | 
			
		||||
to create an XML file at ``path``.
 | 
			
		||||
 | 
			
		||||
creating resultlog format files
 | 
			
		||||
----------------------------------------------------
 | 
			
		||||
 | 
			
		||||
To create plain-text machine-readable result files you can issue::
 | 
			
		||||
 | 
			
		||||
    py.test --resultlog=path
 | 
			
		||||
 | 
			
		||||
and look at the content at the ``path`` location.  Such files are used e.g.
 | 
			
		||||
by the `PyPy-test`_ web page to show test results over several revisions.
 | 
			
		||||
 | 
			
		||||
.. _`PyPy-test`: http://codespeak.net:8099/summary
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
send test report to pocoo pastebin service
 | 
			
		||||
-----------------------------------------------------
 | 
			
		||||
 | 
			
		||||
**Creating a URL for each test failure**::
 | 
			
		||||
 | 
			
		||||
    py.test --pastebin=failed
 | 
			
		||||
 | 
			
		||||
This will submit test run information to a remote Paste service and
 | 
			
		||||
provide a URL for each failure.  You may select tests as usual or add
 | 
			
		||||
for example ``-x`` if you only want to send one particular failure.
 | 
			
		||||
 | 
			
		||||
**Creating a URL for a whole test session log**::
 | 
			
		||||
 | 
			
		||||
    py.test --pastebin=all
 | 
			
		||||
 | 
			
		||||
Currently only pasting to the http://paste.pocoo.org service is implemented.
 | 
			
		||||
 | 
			
		||||
.. include:: links.inc
 | 
			
		||||
| 
						 | 
				
			
			@ -64,7 +64,7 @@ release = '2.0.0dev0'
 | 
			
		|||
 | 
			
		||||
# List of patterns, relative to source directory, that match files and
 | 
			
		||||
# directories to ignore when looking for source files.
 | 
			
		||||
exclude_patterns = ['_build', 'example', 'test', 'announce'] # XXX
 | 
			
		||||
exclude_patterns = ['_build', 'test', 'announce'] # XXX
 | 
			
		||||
 | 
			
		||||
# The reST default role (used for this markup: `text`) to use for all documents.
 | 
			
		||||
#default_role = None
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -1,59 +0,0 @@
 | 
			
		|||
 | 
			
		||||
debugging Python failures
 | 
			
		||||
=================================================================
 | 
			
		||||
 | 
			
		||||
Stopping after the first (or N) failures
 | 
			
		||||
----------------------------------------------------
 | 
			
		||||
 | 
			
		||||
To stop the testing process after the first (N) failures::
 | 
			
		||||
 | 
			
		||||
    py.test -x            # stop after first failure
 | 
			
		||||
    py.test -maxfail=2    # stop after two failures
 | 
			
		||||
 | 
			
		||||
Modifying traceback printing
 | 
			
		||||
----------------------------------------------------
 | 
			
		||||
 | 
			
		||||
Examples for modifying traceback printing::
 | 
			
		||||
 | 
			
		||||
    py.test --showlocals # show local variables in tracebacks
 | 
			
		||||
    py.test -l           # show local variables (shortcut)
 | 
			
		||||
 | 
			
		||||
    py.test --tb=long    # the default informative traceback formatting
 | 
			
		||||
    py.test --tb=native  # the Python standard library formatting
 | 
			
		||||
    py.test --tb=short   # a shorter traceback format
 | 
			
		||||
    py.test --tb=line    # only one line per failure
 | 
			
		||||
 | 
			
		||||
Dropping to PDB (Python Debugger) on failures
 | 
			
		||||
----------------------------------------------------
 | 
			
		||||
 | 
			
		||||
.. _PDB: http://docs.python.org/library/pdb.html
 | 
			
		||||
 | 
			
		||||
Python comes with a builtin Python debugger called PDB_.  ``py.test`` 
 | 
			
		||||
allows to drop into the PDB prompt via a command line option::
 | 
			
		||||
 | 
			
		||||
    py.test --pdb
 | 
			
		||||
 | 
			
		||||
This will invoke the Python debugger on every failure.  Often you might
 | 
			
		||||
only want to do this for the first failing test to understand a certain
 | 
			
		||||
failure situation::
 | 
			
		||||
 | 
			
		||||
    py.test -x --pdb   # drop to PDB on first failure, then end test session
 | 
			
		||||
    py.test --pdb --maxfail=3  # drop to PDB for the first three failures
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
Setting a breakpoint / aka ``set_trace()``
 | 
			
		||||
----------------------------------------------------
 | 
			
		||||
 | 
			
		||||
If you want to set a breakpoint and enter the ``pdb.set_trace()`` you
 | 
			
		||||
can use a helper::
 | 
			
		||||
 | 
			
		||||
    def test_function():
 | 
			
		||||
        ...
 | 
			
		||||
        py.test.set_trace()    # invoke PDB debugger and tracing
 | 
			
		||||
 | 
			
		||||
.. versionadded: 2.0.0
 | 
			
		||||
 | 
			
		||||
In previous versions you could only enter PDB tracing if
 | 
			
		||||
you :ref:`disable capturing`.
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			@ -6,7 +6,6 @@ Feedback and contribute to py.test
 | 
			
		|||
   :maxdepth: 2
 | 
			
		||||
 | 
			
		||||
   contact.txt
 | 
			
		||||
   faq.txt
 | 
			
		||||
 | 
			
		||||
.. _checkout:
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -1,14 +0,0 @@
 | 
			
		|||
 | 
			
		||||
Using the command line
 | 
			
		||||
===============================================
 | 
			
		||||
 | 
			
		||||
Example command line usages::
 | 
			
		||||
 | 
			
		||||
    py.test --version   # shows where pytest was imported from
 | 
			
		||||
    py.test --funcargs  # show available builtin function arguments
 | 
			
		||||
    py.test --help-config # show configuration values
 | 
			
		||||
    
 | 
			
		||||
    py.test -h | --help # show help
 | 
			
		||||
    
 | 
			
		||||
 | 
			
		||||
which tells you both version and import location of the tool.
 | 
			
		||||
| 
						 | 
				
			
			@ -0,0 +1,60 @@
 | 
			
		|||
 | 
			
		||||
Customizing test function through marks and hooks
 | 
			
		||||
====================================================
 | 
			
		||||
 | 
			
		||||
.. _`retrieved by hooks as item keywords`:
 | 
			
		||||
 | 
			
		||||
control skipping of tests according to command line option
 | 
			
		||||
--------------------------------------------------------------
 | 
			
		||||
 | 
			
		||||
Here is a ``conftest.py`` file adding a ``--runslow`` command
 | 
			
		||||
line option to control skipping of ``slow`` marked tests::
 | 
			
		||||
 | 
			
		||||
    # content of conftest.py
 | 
			
		||||
    
 | 
			
		||||
    import py
 | 
			
		||||
    def pytest_addoption(parser):
 | 
			
		||||
        parser.addoption("--runslow", action="store_true",
 | 
			
		||||
            help="run slow tests")
 | 
			
		||||
 | 
			
		||||
    def pytest_runtest_setup(item):
 | 
			
		||||
        if 'slow' in item.keywords and not item.config.getvalue("runslow"):
 | 
			
		||||
            py.test.skip("need --runslow option to run")
 | 
			
		||||
 | 
			
		||||
We can now write a test module like this::
 | 
			
		||||
 | 
			
		||||
    # content of test_module.py
 | 
			
		||||
    
 | 
			
		||||
    import py
 | 
			
		||||
    slow = py.test.mark.slow
 | 
			
		||||
 | 
			
		||||
    def test_func_fast():
 | 
			
		||||
        pass
 | 
			
		||||
 | 
			
		||||
    @slow
 | 
			
		||||
    def test_func_slow():
 | 
			
		||||
        pass
 | 
			
		||||
 | 
			
		||||
and when running it will see a skipped "slow" test::
 | 
			
		||||
 | 
			
		||||
    $ py.test test_module.py -rs    # "-rs" means report on the little 's'
 | 
			
		||||
    =========================== test session starts ============================
 | 
			
		||||
    platform linux2 -- Python 2.6.5 -- pytest-2.0.0dev0
 | 
			
		||||
    test path 1: test_module.py
 | 
			
		||||
    
 | 
			
		||||
    test_module.py .s
 | 
			
		||||
    ========================= short test summary info ==========================
 | 
			
		||||
    SKIP [1] /tmp/doc-exec-12/conftest.py:9: 'need --runslow option to run'
 | 
			
		||||
    
 | 
			
		||||
    =================== 1 passed, 1 skipped in 0.02 seconds ====================
 | 
			
		||||
 | 
			
		||||
Or run it including the ``slow`` marked test::
 | 
			
		||||
 | 
			
		||||
    $ py.test test_module.py --runslow
 | 
			
		||||
    =========================== test session starts ============================
 | 
			
		||||
    platform linux2 -- Python 2.6.5 -- pytest-2.0.0dev0
 | 
			
		||||
    test path 1: test_module.py
 | 
			
		||||
    
 | 
			
		||||
    test_module.py ..
 | 
			
		||||
    
 | 
			
		||||
    ========================= 2 passed in 0.01 seconds =========================
 | 
			
		||||
| 
						 | 
				
			
			@ -0,0 +1,138 @@
 | 
			
		|||
 | 
			
		||||
.. highlightlang:: python
 | 
			
		||||
 | 
			
		||||
mysetup pattern: application specific test fixtures
 | 
			
		||||
==========================================================
 | 
			
		||||
 | 
			
		||||
Here is a basic useful step-by-step example for managing and interacting
 | 
			
		||||
with application specific test setup.  The goal is to have one place
 | 
			
		||||
where we have the glue and test support code for bootstrapping and
 | 
			
		||||
configuring application objects and allow test modules and test
 | 
			
		||||
functions to stay ignorant of involved details.
 | 
			
		||||
 | 
			
		||||
step1: implementing the test/app-specific ``mysetup`` pattern
 | 
			
		||||
-------------------------------------------------------------
 | 
			
		||||
 | 
			
		||||
Let's write a simple test function using a ``mysetup`` funcarg::
 | 
			
		||||
 | 
			
		||||
    # content of test_sample.py
 | 
			
		||||
    def test_answer(mysetup):
 | 
			
		||||
        app = mysetup.myapp()
 | 
			
		||||
        answer = app.question()
 | 
			
		||||
        assert answer == 42
 | 
			
		||||
 | 
			
		||||
To run this test py.test needs to find and call a factory to
 | 
			
		||||
obtain the required ``mysetup`` function argument.  To make
 | 
			
		||||
an according factory findable we write down a specifically named factory
 | 
			
		||||
method in a :ref:`local plugin`::
 | 
			
		||||
 | 
			
		||||
    # content of conftest.py
 | 
			
		||||
    from myapp import MyApp
 | 
			
		||||
 | 
			
		||||
    def pytest_funcarg__mysetup(request): # "mysetup" factory function
 | 
			
		||||
        return MySetup()
 | 
			
		||||
 | 
			
		||||
    class MySetup: # instances of this are seen by test functions
 | 
			
		||||
        def myapp(self):
 | 
			
		||||
            return MyApp()
 | 
			
		||||
 | 
			
		||||
To run the example we stub out a a simple ``MyApp`` application object::
 | 
			
		||||
 | 
			
		||||
    # content of myapp.py
 | 
			
		||||
    class MyApp:
 | 
			
		||||
        def question(self):
 | 
			
		||||
            return 6 * 9
 | 
			
		||||
 | 
			
		||||
You can now run the test::
 | 
			
		||||
 | 
			
		||||
    $ py.test test_sample.py
 | 
			
		||||
    =========================== test session starts ============================
 | 
			
		||||
    platform linux2 -- Python 2.6.5 -- pytest-2.0.0dev0
 | 
			
		||||
    test path 1: test_sample.py
 | 
			
		||||
    
 | 
			
		||||
    test_sample.py F
 | 
			
		||||
    
 | 
			
		||||
    ================================= FAILURES =================================
 | 
			
		||||
    _______________________________ test_answer ________________________________
 | 
			
		||||
    
 | 
			
		||||
    mysetup = <conftest.MySetup instance at 0x1a09f38>
 | 
			
		||||
    
 | 
			
		||||
        def test_answer(mysetup):
 | 
			
		||||
            app = mysetup.myapp()
 | 
			
		||||
            answer = app.question()
 | 
			
		||||
    >       assert answer == 42
 | 
			
		||||
    E       assert 54 == 42
 | 
			
		||||
    
 | 
			
		||||
    test_sample.py:4: AssertionError
 | 
			
		||||
    ========================= 1 failed in 0.02 seconds =========================
 | 
			
		||||
 | 
			
		||||
This means that our ``mysetup`` object was successfully instantiated
 | 
			
		||||
and ``mysetup.app()`` returned an initialized ``MyApp`` instance.
 | 
			
		||||
We can ask it about the question and if you are confused as to what
 | 
			
		||||
the concrete question or answers actually mean, please see here_.
 | 
			
		||||
 | 
			
		||||
.. _here: http://uncyclopedia.wikia.com/wiki/The_Hitchhiker's_Guide_to_the_Galaxy
 | 
			
		||||
.. _`tut-cmdlineoption`:
 | 
			
		||||
 | 
			
		||||
step 2: checking a command line option and skipping tests
 | 
			
		||||
-----------------------------------------------------------
 | 
			
		||||
 | 
			
		||||
To add a command line option we update the ``conftest.py`` of
 | 
			
		||||
the previous example to add a command line option
 | 
			
		||||
and to offer a new mysetup method::
 | 
			
		||||
 | 
			
		||||
    # content of ./conftest.py
 | 
			
		||||
    import py
 | 
			
		||||
    from myapp import MyApp
 | 
			
		||||
 | 
			
		||||
    def pytest_funcarg__mysetup(request): # "mysetup" factory function
 | 
			
		||||
        return MySetup(request)
 | 
			
		||||
 | 
			
		||||
    def pytest_addoption(parser):
 | 
			
		||||
        parser.addoption("--ssh", action="store", default=None,
 | 
			
		||||
            help="specify ssh host to run tests with")
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
    class MySetup:
 | 
			
		||||
        def __init__(self, request):
 | 
			
		||||
            self.config = request.config
 | 
			
		||||
 | 
			
		||||
        def myapp(self):
 | 
			
		||||
            return MyApp()
 | 
			
		||||
 | 
			
		||||
        def getsshconnection(self):
 | 
			
		||||
            host = self.config.option.ssh
 | 
			
		||||
            if host is None:
 | 
			
		||||
                py.test.skip("specify ssh host with --ssh")
 | 
			
		||||
            return execnet.SshGateway(host)
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
Now any test function can use the ``mysetup.getsshconnection()`` method
 | 
			
		||||
like this::
 | 
			
		||||
 | 
			
		||||
    # content of test_ssh.py
 | 
			
		||||
    class TestClass:
 | 
			
		||||
        def test_function(self, mysetup):
 | 
			
		||||
            conn = mysetup.getsshconnection()
 | 
			
		||||
            # work with conn
 | 
			
		||||
 | 
			
		||||
Running it yields::
 | 
			
		||||
 | 
			
		||||
    $ py.test test_ssh.py -rs
 | 
			
		||||
    =========================== test session starts ============================
 | 
			
		||||
    platform linux2 -- Python 2.6.5 -- pytest-2.0.0dev0
 | 
			
		||||
    test path 1: test_ssh.py
 | 
			
		||||
    
 | 
			
		||||
    test_ssh.py s
 | 
			
		||||
    ========================= short test summary info ==========================
 | 
			
		||||
    SKIP [1] /tmp/doc-exec-9/conftest.py:22: 'specify ssh host with --ssh'
 | 
			
		||||
    
 | 
			
		||||
    ======================== 1 skipped in 0.02 seconds =========================
 | 
			
		||||
 | 
			
		||||
If you specify a command line option like ``py.test --ssh=python.org`` the test will execute as expected.
 | 
			
		||||
 | 
			
		||||
Note that neither the ``TestClass`` nor the ``test_function`` need to
 | 
			
		||||
know anything about how to setup the test state.  It is handled separately
 | 
			
		||||
in your "test setup glue" code in the ``conftest.py`` file.  It is easy
 | 
			
		||||
to extend the ``mysetup`` object for further needs in the test code - and for use by any other test functions in the files and directories below the ``conftest.py`` file.
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			@ -1,71 +0,0 @@
 | 
			
		|||
.. _`setuptools installation`: http://pypi.python.org/pypi/setuptools
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
==================
 | 
			
		||||
Quickstart
 | 
			
		||||
==================
 | 
			
		||||
 | 
			
		||||
.. _here: ../install.html
 | 
			
		||||
 | 
			
		||||
If you have the ``easy_install`` tool (otherwise see here_) just type:
 | 
			
		||||
    
 | 
			
		||||
 | 
			
		||||
    easy_install -U py
 | 
			
		||||
 | 
			
		||||
Now create a file ``test_sample.py`` with the following content:
 | 
			
		||||
 | 
			
		||||
.. sourcecode:: python
 | 
			
		||||
 | 
			
		||||
    # content of test_sample.py
 | 
			
		||||
    def func(x):
 | 
			
		||||
        return x + 1
 | 
			
		||||
    def test_answer():
 | 
			
		||||
        assert func(3) == 5
 | 
			
		||||
 | 
			
		||||
You can now run the test file like this::
 | 
			
		||||
 | 
			
		||||
    py.test test_sample.py
 | 
			
		||||
 | 
			
		||||
and will see output like this:
 | 
			
		||||
 | 
			
		||||
.. sourcecode:: python
 | 
			
		||||
 | 
			
		||||
    =========================== test session starts ============================
 | 
			
		||||
    python: platform linux2 -- Python 2.6.2 -- pytest-1.1.0
 | 
			
		||||
    test object 1: test_sample.py
 | 
			
		||||
 | 
			
		||||
    test_sample.py F
 | 
			
		||||
 | 
			
		||||
    ================================= FAILURES =================================
 | 
			
		||||
    _______________________________ test_answer ________________________________
 | 
			
		||||
 | 
			
		||||
        def test_answer():
 | 
			
		||||
    >       assert func(3) == 5
 | 
			
		||||
    E       assert 4 == 5
 | 
			
		||||
    E        +  where 4 = func(3)
 | 
			
		||||
 | 
			
		||||
    test_sample.py:6: AssertionError
 | 
			
		||||
    ========================= 1 failed in 0.08 seconds =========================
 | 
			
		||||
 | 
			
		||||
This output contains Python interpreter information, a list of test objects,
 | 
			
		||||
a progress report and important details of the failure.
 | 
			
		||||
 | 
			
		||||
**Where to go from here**
 | 
			
		||||
 | 
			
		||||
`features`_: overview and description of test features
 | 
			
		||||
 | 
			
		||||
`plugins`_: a list of available plugins which each contain usage examples
 | 
			
		||||
 | 
			
		||||
`tutorials`_: some blog entries and starting points with code examples
 | 
			
		||||
 | 
			
		||||
`contact`_: if you want to feedback or have problems
 | 
			
		||||
 | 
			
		||||
.. _`contact`: ../contact.html
 | 
			
		||||
.. _`automatically collected`: features.html#autocollect
 | 
			
		||||
.. _install: ../install.html
 | 
			
		||||
.. _plugins: plugin/index.html
 | 
			
		||||
.. _features: features.html
 | 
			
		||||
.. _tutorials: talks.html
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			@ -1,8 +1,9 @@
 | 
			
		|||
 | 
			
		||||
Examples for writing tests
 | 
			
		||||
Usages and Examples
 | 
			
		||||
===========================================
 | 
			
		||||
 | 
			
		||||
.. toctree::
 | 
			
		||||
   :maxdepth: 2
 | 
			
		||||
 | 
			
		||||
   example/funcarg_simple.txt
 | 
			
		||||
   example/marking.txt
 | 
			
		||||
   example/mysetup.txt
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
							
								
								
									
										25
									
								
								doc/faq.txt
								
								
								
								
							
							
						
						
									
										25
									
								
								doc/faq.txt
								
								
								
								
							| 
						 | 
				
			
			@ -1,6 +1,29 @@
 | 
			
		|||
Frequently asked Questions
 | 
			
		||||
Frequent Issues and Questions
 | 
			
		||||
==================================
 | 
			
		||||
 | 
			
		||||
.. _`installation issues`:
 | 
			
		||||
 | 
			
		||||
Installation issues
 | 
			
		||||
------------------------------
 | 
			
		||||
 | 
			
		||||
easy_install or py.test not found on Windows machine
 | 
			
		||||
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 | 
			
		||||
 | 
			
		||||
- **Windows**: If "easy_install" or "py.test" are not found
 | 
			
		||||
  please see here for preparing your environment for running
 | 
			
		||||
  command line tools: `Python for Windows`_.  You may alternatively
 | 
			
		||||
  use an `ActivePython install`_ which makes command line tools
 | 
			
		||||
  automatically available under Windows.
 | 
			
		||||
 | 
			
		||||
.. _`ActivePython install`: http://www.activestate.com/activepython/downloads
 | 
			
		||||
 | 
			
		||||
.. _`Jython does not create command line launchers`: http://bugs.jython.org/issue1491
 | 
			
		||||
 | 
			
		||||
- **Jython2.5.1 on Windows XP**: `Jython does not create command line launchers`_
 | 
			
		||||
  so ``py.test`` will not work correctly.  You may install py.test on
 | 
			
		||||
  CPython and type ``py.test --genscript=mytest`` and then use
 | 
			
		||||
  ``jython mytest`` to run py.test for your tests to run in Jython.
 | 
			
		||||
 | 
			
		||||
On naming, nosetests, licensing and magic XXX
 | 
			
		||||
------------------------------------------------
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -1,14 +1,14 @@
 | 
			
		|||
py.test Features
 | 
			
		||||
==================
 | 
			
		||||
 | 
			
		||||
mature command line testing tool
 | 
			
		||||
--------------------------------------
 | 
			
		||||
no-boilerplate testing with Python
 | 
			
		||||
----------------------------------
 | 
			
		||||
 | 
			
		||||
- used in many projects, ranging from 10 to 10K tests
 | 
			
		||||
- simple well sorted command line options
 | 
			
		||||
- runs on Unix, Windows from Python 2.4 up to Python 3.1 and 3.2
 | 
			
		||||
- is itself tested extensively on a CI server
 | 
			
		||||
- keyword/testname based selection of tests
 | 
			
		||||
- automatic customizable Python test discovery
 | 
			
		||||
- powerful parametrization of test functions
 | 
			
		||||
- use the ``assert`` statement for your assertions
 | 
			
		||||
- rely on powerful traceback and assertion reporting
 | 
			
		||||
- use ``print`` or ``pdb`` debugging on failures
 | 
			
		||||
 | 
			
		||||
extensive plugin and customization system
 | 
			
		||||
------------------------------------------------------
 | 
			
		||||
| 
						 | 
				
			
			@ -20,6 +20,16 @@ extensive plugin and customization system
 | 
			
		|||
- it is `suprisingly easy`_ to add command line options or
 | 
			
		||||
  do other kind of add-ons and customizations.
 | 
			
		||||
 | 
			
		||||
mature command line testing tool
 | 
			
		||||
--------------------------------------
 | 
			
		||||
 | 
			
		||||
- used in many projects, ranging from 10 to 10K tests
 | 
			
		||||
- autodiscovery of tests
 | 
			
		||||
- simple well sorted command line options
 | 
			
		||||
- runs on Unix, Windows from Python 2.4 up to Python 3.1 and 3.2
 | 
			
		||||
- is itself tested extensively on a CI server
 | 
			
		||||
- keyword/testname based selection of tests
 | 
			
		||||
 | 
			
		||||
integrates well with CI systems
 | 
			
		||||
----------------------------------------
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			@ -29,14 +39,6 @@ integrates well with CI systems
 | 
			
		|||
 | 
			
		||||
.. _`tox`: http://codespeak.net/tox
 | 
			
		||||
 | 
			
		||||
no-boilerplate testing with Python
 | 
			
		||||
----------------------------------
 | 
			
		||||
 | 
			
		||||
- automatic customizable Python test discovery
 | 
			
		||||
- powerful parametrization of test functions
 | 
			
		||||
- use the ``assert`` statement for your assertions
 | 
			
		||||
- rely on powerful traceback and assertion reporting
 | 
			
		||||
- use ``print`` or ``pdb`` debugging on failures
 | 
			
		||||
 | 
			
		||||
supports several testing practises and methods
 | 
			
		||||
-----------------------------------------------------------
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -1,5 +1,5 @@
 | 
			
		|||
==============================================================
 | 
			
		||||
funcargs: creating and managing test function arguments
 | 
			
		||||
creating and managing test function arguments
 | 
			
		||||
==============================================================
 | 
			
		||||
 | 
			
		||||
.. currentmodule:: pytest.plugin.python
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -0,0 +1,43 @@
 | 
			
		|||
 | 
			
		||||
Good Practises
 | 
			
		||||
=================================================
 | 
			
		||||
 | 
			
		||||
Recommendation: install tool and dependencies virtually
 | 
			
		||||
-----------------------------------------------------------
 | 
			
		||||
 | 
			
		||||
We recommend to work with virtual environments
 | 
			
		||||
(e.g. virtualenv_ or buildout_ based) and use easy_install_
 | 
			
		||||
(or pip_) for installing py.test/pylib and any dependencies
 | 
			
		||||
you need to run your tests.  Local virtual Python environments
 | 
			
		||||
(as opposed to system-wide "global" environments) make for a more
 | 
			
		||||
reproducible and reliable test environment.
 | 
			
		||||
 | 
			
		||||
.. _`virtualenv`: http://pypi.python.org/pypi/virtualenv
 | 
			
		||||
.. _`buildout`: http://www.buildout.org/
 | 
			
		||||
.. _pip: http://pypi.python.org/pypi/pip
 | 
			
		||||
 | 
			
		||||
.. _standalone:
 | 
			
		||||
 | 
			
		||||
Generating a py.test standalone Script
 | 
			
		||||
-------------------------------------------
 | 
			
		||||
 | 
			
		||||
If you are a maintainer or application developer and want users
 | 
			
		||||
to run tests you can use a facility to generate a standalone
 | 
			
		||||
"py.test" script that you can tell users to run::
 | 
			
		||||
 | 
			
		||||
    py.test --genscript=mytest
 | 
			
		||||
 | 
			
		||||
will generate a ``mytest`` script that is, in fact, a ``py.test`` under
 | 
			
		||||
disguise.  You can tell people to download and then e.g. run it like this::
 | 
			
		||||
 | 
			
		||||
    python mytest --pastebin=all
 | 
			
		||||
 | 
			
		||||
and ask them to send you the resulting URL.  The resulting script has
 | 
			
		||||
all core features and runs unchanged under Python2 and Python3 interpreters.
 | 
			
		||||
 | 
			
		||||
.. _`Python for Windows`: http://www.imladris.com/Scripts/PythonForWindows.html
 | 
			
		||||
 | 
			
		||||
.. _`Distribute for installation`: http://pypi.python.org/pypi/distribute#installation-instructions
 | 
			
		||||
.. _`distribute installation`: http://pypi.python.org/pypi/distribute
 | 
			
		||||
 | 
			
		||||
.. include:: links.inc
 | 
			
		||||
| 
						 | 
				
			
			@ -1,14 +1,7 @@
 | 
			
		|||
.. pytest documentation master file, created by
 | 
			
		||||
   sphinx-quickstart on Fri Oct  8 17:54:28 2010.
 | 
			
		||||
   You can adapt this file completely to your liking, but it should at least
 | 
			
		||||
   contain the root `toctree` directive.
 | 
			
		||||
py.test: no-boilerplate testing with Python
 | 
			
		||||
==============================================
 | 
			
		||||
   
 | 
			
		||||
py.test: no-boilerplate rapid testing with Python
 | 
			
		||||
======================================================
 | 
			
		||||
 | 
			
		||||
Welcome to ``py.test`` documentation.
 | 
			
		||||
 | 
			
		||||
Contents:
 | 
			
		||||
Welcome to ``py.test`` documentation:
 | 
			
		||||
 | 
			
		||||
.. toctree:: 
 | 
			
		||||
   :maxdepth: 2
 | 
			
		||||
| 
						 | 
				
			
			@ -25,7 +18,6 @@ Contents:
 | 
			
		|||
 | 
			
		||||
   changelog.txt
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
Indices and tables
 | 
			
		||||
==================
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -13,76 +13,21 @@ installing py.test
 | 
			
		|||
Installation using easy_install
 | 
			
		||||
----------------------------------------
 | 
			
		||||
 | 
			
		||||
You need setuptools_ or Distribute_ to be able to simply type::
 | 
			
		||||
If you have setuptools_ or Distribute_ type::
 | 
			
		||||
 | 
			
		||||
    easy_install -U pytest
 | 
			
		||||
 | 
			
		||||
to install the latest release of ``py.test``.  The ``-U`` switch
 | 
			
		||||
triggers an upgrade if you already have an older version installed.
 | 
			
		||||
Note that setuptools works ok with Python2 interpreters while `Distribute`_
 | 
			
		||||
additionally works with Python3 and also avoid some issues on Windows.
 | 
			
		||||
Note that setuptools works ok with Python2 interpreters while **Distribute
 | 
			
		||||
works with Python3 and Python2** and also avoids some issues on Windows.
 | 
			
		||||
 | 
			
		||||
Known issues:
 | 
			
		||||
You should now be able to type::
 | 
			
		||||
 | 
			
		||||
- **Windows**: If "easy_install" or "py.test" are not found
 | 
			
		||||
  please see here for preparing your environment for running
 | 
			
		||||
  command line tools: `Python for Windows`_.  You may alternatively
 | 
			
		||||
  use an `ActivePython install`_ which makes command line tools
 | 
			
		||||
  automatically available under Windows.
 | 
			
		||||
    $ py.test --version
 | 
			
		||||
 | 
			
		||||
.. _`ActivePython install`: http://www.activestate.com/activepython/downloads
 | 
			
		||||
 | 
			
		||||
.. _`Jython does not create command line launchers`: http://bugs.jython.org/issue1491
 | 
			
		||||
 | 
			
		||||
- **Jython2.5.1 on Windows XP**: `Jython does not create command line launchers`_
 | 
			
		||||
  so ``py.test`` will not work correctly.  You may install py.test on
 | 
			
		||||
  CPython and type ``py.test --genscript=mytest`` and then use
 | 
			
		||||
  ``jython mytest`` to run py.test for your tests to run in Jython.
 | 
			
		||||
 | 
			
		||||
- **On Linux**: If ``easy_install`` fails because it needs to run
 | 
			
		||||
  as the superuser you are trying to install things globally
 | 
			
		||||
  and need to put ``sudo`` in front of the command.
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
.. _quickstart: test/quickstart.html
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
Recommendation: install tool and dependencies virtually
 | 
			
		||||
-----------------------------------------------------------
 | 
			
		||||
 | 
			
		||||
I recommend to work with virtual environments
 | 
			
		||||
(e.g. virtualenv_ or buildout_ based) and use easy_install_
 | 
			
		||||
(or pip_) for installing py.test/pylib and any dependencies
 | 
			
		||||
you need to run your tests.  Local virtual Python environments
 | 
			
		||||
(as opposed to system-wide "global" environments) make for a more
 | 
			
		||||
reproducible and reliable test environment.
 | 
			
		||||
 | 
			
		||||
.. _`virtualenv`: http://pypi.python.org/pypi/virtualenv
 | 
			
		||||
.. _`buildout`: http://www.buildout.org/
 | 
			
		||||
.. _pip: http://pypi.python.org/pypi/pip
 | 
			
		||||
 | 
			
		||||
.. _standalone:
 | 
			
		||||
 | 
			
		||||
Generating a py.test standalone Script
 | 
			
		||||
-------------------------------------------
 | 
			
		||||
 | 
			
		||||
If you are a maintainer or application developer and want users
 | 
			
		||||
to run tests you can use a facility to generate a standalone
 | 
			
		||||
"py.test" script that you can tell users to run::
 | 
			
		||||
 | 
			
		||||
    py.test --genscript=mytest
 | 
			
		||||
 | 
			
		||||
will generate a ``mytest`` script that is, in fact, a ``py.test`` under
 | 
			
		||||
disguise.  You can tell people to download and then e.g. run it like this::
 | 
			
		||||
 | 
			
		||||
    python mytest --pastebin=all
 | 
			
		||||
 | 
			
		||||
and ask them to send you the resulting URL.  The resulting script has
 | 
			
		||||
all core features and runs unchanged under Python2 and Python3 interpreters.
 | 
			
		||||
 | 
			
		||||
.. _`Python for Windows`: http://www.imladris.com/Scripts/PythonForWindows.html
 | 
			
		||||
 | 
			
		||||
.. _`Distribute for installation`: http://pypi.python.org/pypi/distribute#installation-instructions
 | 
			
		||||
.. _`distribute installation`: http://pypi.python.org/pypi/distribute
 | 
			
		||||
Refer to :ref:`installation issues` if you have issues.
 | 
			
		||||
 | 
			
		||||
.. include:: links.inc
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
							
								
								
									
										37
									
								
								doc/mark.txt
								
								
								
								
							
							
						
						
									
										37
									
								
								doc/mark.txt
								
								
								
								
							| 
						 | 
				
			
			@ -1,9 +1,11 @@
 | 
			
		|||
 | 
			
		||||
.. _mark:
 | 
			
		||||
 | 
			
		||||
mark (attribute) python functions
 | 
			
		||||
mark test functions with attributes
 | 
			
		||||
=================================================================
 | 
			
		||||
 | 
			
		||||
.. currentmodule:: pytest.plugin.mark
 | 
			
		||||
 | 
			
		||||
By using the ``py.test.mark`` helper you can instantiate
 | 
			
		||||
decorators that will set named meta data on test functions.
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			@ -17,7 +19,7 @@ You can "mark" a test function with meta data like this::
 | 
			
		|||
    def test_send_http():
 | 
			
		||||
        ...
 | 
			
		||||
 | 
			
		||||
This will set the function attribute ``webtest`` to a :py:meth:`MarkInfo` 
 | 
			
		||||
This will set the function attribute ``webtest`` to a :py:class:`MarkInfo` 
 | 
			
		||||
instance.  You can also specify parametrized meta data like this::
 | 
			
		||||
 | 
			
		||||
    # content of test_mark.py
 | 
			
		||||
| 
						 | 
				
			
			@ -79,15 +81,15 @@ You can also set a module level marker::
 | 
			
		|||
in which case it will be applied to all functions and
 | 
			
		||||
methods defined in the module.
 | 
			
		||||
 | 
			
		||||
Using "-k MARKNAME" to select tests
 | 
			
		||||
Using ``-k TEXT`` to select tests
 | 
			
		||||
----------------------------------------------------
 | 
			
		||||
 | 
			
		||||
You can use the ``-k`` command line option to select tests::
 | 
			
		||||
 | 
			
		||||
    $ py.test -k webtest  # will only run tests marked as webtest
 | 
			
		||||
    $ py.test -k webtest  # running with the above defined examples yields
 | 
			
		||||
    =========================== test session starts ============================
 | 
			
		||||
    platform linux2 -- Python 2.6.5 -- pytest-2.0.0dev0
 | 
			
		||||
    test path 1: /tmp/doc-exec-335
 | 
			
		||||
    test path 1: /tmp/doc-exec-11
 | 
			
		||||
    
 | 
			
		||||
    test_mark.py ..
 | 
			
		||||
    test_mark_classlevel.py ..
 | 
			
		||||
| 
						 | 
				
			
			@ -96,16 +98,35 @@ You can use the ``-k`` command line option to select tests::
 | 
			
		|||
 | 
			
		||||
And you can also run all tests except the ones that match the keyword::
 | 
			
		||||
 | 
			
		||||
    $ py.test -k-webtest  # "-" negates but be careful to have no space before
 | 
			
		||||
    $ py.test -k-webtest
 | 
			
		||||
    =========================== test session starts ============================
 | 
			
		||||
    platform linux2 -- Python 2.6.5 -- pytest-2.0.0dev0
 | 
			
		||||
    test path 1: /tmp/doc-exec-335
 | 
			
		||||
    test path 1: /tmp/doc-exec-11
 | 
			
		||||
    
 | 
			
		||||
    ===================== 4 tests deselected by '-webtest' =====================
 | 
			
		||||
    ======================= 4 deselected in 0.01 seconds =======================
 | 
			
		||||
 | 
			
		||||
Or to only select the class::
 | 
			
		||||
 | 
			
		||||
    $ py.test -kTestClass
 | 
			
		||||
    =========================== test session starts ============================
 | 
			
		||||
    platform linux2 -- Python 2.6.5 -- pytest-2.0.0dev0
 | 
			
		||||
    test path 1: /tmp/doc-exec-11
 | 
			
		||||
    
 | 
			
		||||
    test_mark_classlevel.py ..
 | 
			
		||||
    
 | 
			
		||||
    ==================== 2 tests deselected by 'TestClass' =====================
 | 
			
		||||
    ================== 2 passed, 2 deselected in 0.01 seconds ==================
 | 
			
		||||
 | 
			
		||||
API reference for mark related objects
 | 
			
		||||
------------------------------------------------
 | 
			
		||||
 | 
			
		||||
.. autoclass:: pytest.plugin.mark.MarkInfo
 | 
			
		||||
.. autoclass:: MarkGenerator
 | 
			
		||||
    :members:
 | 
			
		||||
 | 
			
		||||
.. autoclass:: MarkDecorator
 | 
			
		||||
    :members:
 | 
			
		||||
 | 
			
		||||
.. autoclass:: MarkInfo
 | 
			
		||||
    :members:
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -7,4 +7,8 @@ Overview and Introduction
 | 
			
		|||
 | 
			
		||||
   features.txt
 | 
			
		||||
   install.txt
 | 
			
		||||
   basic_usage.txt
 | 
			
		||||
   cmdline.txt
 | 
			
		||||
   goodpractises.txt
 | 
			
		||||
   faq.txt
 | 
			
		||||
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -1,44 +0,0 @@
 | 
			
		|||
XML, pastebin services and other reporting
 | 
			
		||||
=================================================================
 | 
			
		||||
 | 
			
		||||
creating JUnitXML format files
 | 
			
		||||
----------------------------------------------------
 | 
			
		||||
 | 
			
		||||
To create result files which can be read by Hudson_ or other Continous
 | 
			
		||||
integration servers, use this invocation::
 | 
			
		||||
 | 
			
		||||
    py.test --junitxml=path
 | 
			
		||||
 | 
			
		||||
to create an XML file at ``path``.
 | 
			
		||||
 | 
			
		||||
creating resultlog format files
 | 
			
		||||
----------------------------------------------------
 | 
			
		||||
 | 
			
		||||
To create plain-text machine-readable result files you can issue::
 | 
			
		||||
 | 
			
		||||
    py.test --resultlog=path
 | 
			
		||||
 | 
			
		||||
and look at the content at the ``path`` location.  Such files are used e.g.
 | 
			
		||||
by the `PyPy-test`_ web page to show test results over several revisions.
 | 
			
		||||
 | 
			
		||||
.. _`PyPy-test`: http://codespeak.net:8099/summary
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
send test report to pocoo pastebin service
 | 
			
		||||
-----------------------------------------------------
 | 
			
		||||
 | 
			
		||||
**Creating a URL for each test failure**::
 | 
			
		||||
 | 
			
		||||
    py.test --pastebin=failed
 | 
			
		||||
 | 
			
		||||
This will submit test run information to a remote Paste service and
 | 
			
		||||
provide a URL for each failure.  You may select tests as usual or add
 | 
			
		||||
for example ``-x`` if you only want to send one particular failure.
 | 
			
		||||
 | 
			
		||||
**Creating a URL for a whole test session log**::
 | 
			
		||||
 | 
			
		||||
    py.test --pastebin=all
 | 
			
		||||
 | 
			
		||||
Currently only pasting to the http://paste.pocoo.org service is implemented.
 | 
			
		||||
 | 
			
		||||
.. include:: links.inc
 | 
			
		||||
| 
						 | 
				
			
			@ -70,16 +70,37 @@ def matchonekeyword(key, chain):
 | 
			
		|||
    return False
 | 
			
		||||
 | 
			
		||||
class MarkGenerator:
 | 
			
		||||
    """ non-underscore attributes of this object can be used as decorators for
 | 
			
		||||
    marking test functions. Example: @py.test.mark.slowtest in front of a
 | 
			
		||||
    function will set the 'slowtest' marker object on it. """
 | 
			
		||||
    """ Factory for :class:`MarkDecorator` objects - exposed as 
 | 
			
		||||
    a ``py.test.mark`` singleton instance.  Example::
 | 
			
		||||
 | 
			
		||||
         import py
 | 
			
		||||
         @py.test.mark.slowtest
 | 
			
		||||
         def test_function():
 | 
			
		||||
            pass
 | 
			
		||||
  
 | 
			
		||||
    will set a 'slowtest' :class:`MarkInfo` object
 | 
			
		||||
    on the ``test_function`` object. """
 | 
			
		||||
 | 
			
		||||
    def __getattr__(self, name):
 | 
			
		||||
        if name[0] == "_":
 | 
			
		||||
            raise AttributeError(name)
 | 
			
		||||
        return MarkDecorator(name)
 | 
			
		||||
 | 
			
		||||
class MarkDecorator:
 | 
			
		||||
    """ decorator for setting function attributes. """
 | 
			
		||||
    """ A decorator for test functions and test classes.  When applied
 | 
			
		||||
    it will create :class:`MarkInfo` objects which may be 
 | 
			
		||||
    :ref:`retrieved by hooks as item keywords`  MarkDecorator instances 
 | 
			
		||||
    are usually created by writing::
 | 
			
		||||
 | 
			
		||||
        mark1 = py.test.mark.NAME              # simple MarkDecorator
 | 
			
		||||
        mark2 = py.test.mark.NAME(name1=value) # parametrized MarkDecorator
 | 
			
		||||
 | 
			
		||||
    and can then be applied as decorators to test functions::
 | 
			
		||||
 | 
			
		||||
        @mark2
 | 
			
		||||
        def test_function():
 | 
			
		||||
            pass
 | 
			
		||||
    """
 | 
			
		||||
    def __init__(self, name):
 | 
			
		||||
        self.markname = name
 | 
			
		||||
        self.kwargs = {}
 | 
			
		||||
| 
						 | 
				
			
			@ -121,9 +142,13 @@ class MarkDecorator:
 | 
			
		|||
        return self
 | 
			
		||||
 | 
			
		||||
class MarkInfo:
 | 
			
		||||
    """ Marking object created by :class:`MarkDecorator` instances. """
 | 
			
		||||
    def __init__(self, name, args, kwargs):
 | 
			
		||||
        self._name = name
 | 
			
		||||
        #: name of attribute
 | 
			
		||||
        self.name = name
 | 
			
		||||
        #: positional argument list, empty if none specified
 | 
			
		||||
        self.args = args
 | 
			
		||||
        #: keyword argument dictionary, empty if nothing specified
 | 
			
		||||
        self.kwargs = kwargs
 | 
			
		||||
 | 
			
		||||
    def __repr__(self):
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
| 
						 | 
				
			
			@ -560,14 +560,12 @@ class FuncargRequest:
 | 
			
		|||
 | 
			
		||||
 | 
			
		||||
    def applymarker(self, marker):
 | 
			
		||||
        """ apply a marker to a test function invocation.
 | 
			
		||||
        Usually markers can be used as decorators for test functions or
 | 
			
		||||
        classes.  However, with parametrized testing a single
 | 
			
		||||
        test function may be called multiple times and ``applymarker``
 | 
			
		||||
        allows to mark only a single invocation.
 | 
			
		||||
 | 
			
		||||
        :param marker: The ``pytest.mark.*`` object to be applied to the test invocation. 
 | 
			
		||||
        """ apply a marker to a single test function invocation.
 | 
			
		||||
        This method is useful if you don't want to have a keyword/marker
 | 
			
		||||
        on all function invocations. 
 | 
			
		||||
 | 
			
		||||
        :arg marker: a :py:class:`pytest.plugin.mark.MarkDecorator` object
 | 
			
		||||
            created by a call to ``py.test.mark.NAME(...)``.
 | 
			
		||||
        """
 | 
			
		||||
        if not isinstance(marker, py.test.mark.XYZ.__class__):
 | 
			
		||||
            raise ValueError("%r is not a py.test.mark.* object")
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
		Loading…
	
		Reference in New Issue