Removed "discussion" session
Kept a note about exceptions after yield not being reraised --HG-- branch : yield-experimental-docs
This commit is contained in:
parent
30260361dd
commit
161d9e5971
|
@ -68,48 +68,13 @@ Note that the yield fixture form supports all other fixture
|
||||||
features such as ``scope``, ``params``, etc., thus changing existing
|
features such as ``scope``, ``params``, etc., thus changing existing
|
||||||
fixture functions to use ``yield`` is straight forward.
|
fixture functions to use ``yield`` is straight forward.
|
||||||
|
|
||||||
Discussion and future considerations / feedback
|
.. note::
|
||||||
++++++++++++++++++++++++++++++++++++++++++++++++++++
|
|
||||||
|
|
||||||
The yield-syntax has been discussed by pytest users extensively.
|
While the ``yield`` syntax is similar to what
|
||||||
In general, the advantages of the using a ``yield`` fixture syntax are:
|
:py:func:`contextlib.contextmanager` decorated functions
|
||||||
|
provide, with pytest fixture functions the part after the
|
||||||
|
"yield" will always be invoked, independently from the
|
||||||
|
exception status of the test function which uses the fixture.
|
||||||
|
This behaviour makes sense if you consider that many different
|
||||||
|
test functions might use a module or session scoped fixture.
|
||||||
|
|
||||||
- easy provision of fixtures in conjunction with context managers.
|
|
||||||
|
|
||||||
- no need to register a callback, providing for more synchronous
|
|
||||||
control flow in the fixture function. Also there is no need to accept
|
|
||||||
the ``request`` object into the fixture function just for providing
|
|
||||||
finalization code.
|
|
||||||
|
|
||||||
However, there are also limitations or foreseeable irritations:
|
|
||||||
|
|
||||||
- usually ``yield`` is used for producing multiple values.
|
|
||||||
But fixture functions can only yield exactly one value.
|
|
||||||
Yielding a second fixture value will get you an error.
|
|
||||||
It's possible we can evolve pytest to allow for producing
|
|
||||||
multiple values as an alternative to current parametrization.
|
|
||||||
For now, you can just use the normal
|
|
||||||
:ref:`fixture parametrization <fixture-parametrize>`
|
|
||||||
mechanisms together with ``yield``-style fixtures.
|
|
||||||
|
|
||||||
- the ``yield`` syntax is similar to what
|
|
||||||
:py:func:`contextlib.contextmanager` decorated functions
|
|
||||||
provide. With pytest fixture functions, the "after yield" part will
|
|
||||||
always be invoked, independently from the exception status
|
|
||||||
of the test function which uses the fixture. The pytest
|
|
||||||
behaviour makes sense if you consider that many different
|
|
||||||
test functions might use a module or session scoped fixture.
|
|
||||||
Some test functions might raise exceptions and others not,
|
|
||||||
so how could pytest re-raise a single exception at the
|
|
||||||
``yield`` point in the fixture function?
|
|
||||||
|
|
||||||
- lastly ``yield`` introduces more than one way to write
|
|
||||||
fixture functions, so what's the obvious way to a newcomer?
|
|
||||||
Newcomers reading the docs will see feature examples using the
|
|
||||||
``return`` style so should use that, if in doubt.
|
|
||||||
Others can start experimenting with writing yield-style fixtures
|
|
||||||
and possibly help evolving them further.
|
|
||||||
|
|
||||||
If you want to feedback or participate in the ongoing
|
|
||||||
discussion, please join our :ref:`contact channels`.
|
|
||||||
you are most welcome.
|
|
||||||
|
|
Loading…
Reference in New Issue