146 lines
6.0 KiB
Plaintext
146 lines
6.0 KiB
Plaintext
Some Issues and Questions
|
|
==================================
|
|
|
|
.. note::
|
|
|
|
If you don't find an answer here, checkout the :ref:`contact channels`
|
|
to get help.
|
|
|
|
On naming, nosetests, licensing and magic
|
|
------------------------------------------------
|
|
|
|
Why a ``py.test`` instead of a ``pytest`` command?
|
|
++++++++++++++++++++++++++++++++++++++++++++++++++
|
|
|
|
Some historic, some practical reasons: ``py.test`` used to be part of
|
|
the ``py`` package which provided several developer utilities,
|
|
all starting with ``py.<TAB>``, providing nice TAB-completion. If
|
|
you install ``pip install pycmd`` you get these tools from a separate
|
|
package. These days the command line tool could be called ``pytest``
|
|
but then again many people have gotten used to the old name and there
|
|
is another tool named "pytest" so we just decided to stick with
|
|
``py.test``.
|
|
|
|
What's the relation to nose and unittest?
|
|
+++++++++++++++++++++++++++++++++++++++++++++++++
|
|
|
|
py.test and nose_ share basic philosophy when it comes
|
|
to running Python tests. In fact, you can run many tests
|
|
written nose with py.test. nose_ was originally created
|
|
as a clone of ``py.test`` when py.test was in the ``0.8`` release
|
|
cycle. As of version 2.0 support for running unittest test
|
|
suites is majorly improved and you should be able to run
|
|
many Django and Twisted test suites.
|
|
|
|
.. _features: test/features.html
|
|
|
|
|
|
What's this "magic" with py.test?
|
|
++++++++++++++++++++++++++++++++++++++++++
|
|
|
|
Around 2007 (version ``0.8``) some people claimed that py.test
|
|
was using too much "magic". It has been refactored a lot. Thrown
|
|
out old code. Deprecated unused approaches and code. And it is today
|
|
probably one of the smallest, most universally runnable and most
|
|
customizable testing frameworks for Python. It's true that
|
|
``py.test`` uses metaprogramming techniques, i.e. it views
|
|
test code similar to how compilers view programs, using a
|
|
somewhat abstract internal model.
|
|
|
|
It's also true that the no-boilerplate testing is implemented by making
|
|
use of the Python assert statement through "re-interpretation":
|
|
When an ``assert`` statement fails, py.test re-interprets the expression
|
|
to show intermediate values if a test fails. If your expression
|
|
has side effects the intermediate values may not be the same, obfuscating
|
|
the initial error (this is also explained at the command line if it happens).
|
|
``py.test --no-assert`` turns off assert re-interpretation.
|
|
Sidenote: it is good practise to avoid asserts with side effects.
|
|
|
|
.. _`py namespaces`: index.html
|
|
.. _`py/__init__.py`: http://bitbucket.org/hpk42/py-trunk/src/trunk/py/__init__.py
|
|
|
|
|
|
function arguments, parametrized tests and setup
|
|
-------------------------------------------------------
|
|
|
|
.. _funcargs: test/funcargs.html
|
|
|
|
Is using funcarg- versus xUnit setup a style question?
|
|
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
|
|
|
For simple applications and for people experienced with nose_ or
|
|
unittest-style test setup using `xUnit style setup`_ often
|
|
feels natural. For larger test suites, parametrized testing
|
|
or setup of complex test resources using funcargs_ may feel more natural.
|
|
Moreover, funcargs are ideal for writing advanced test support
|
|
code (like e.g. the monkeypatch_, the tmpdir_ or capture_ funcargs)
|
|
because the support code can register setup/teardown functions
|
|
in a managed class/module/function scope.
|
|
|
|
.. _monkeypatch: test/plugin/monkeypatch.html
|
|
.. _tmpdir: test/plugin/tmpdir.html
|
|
.. _capture: test/plugin/capture.html
|
|
|
|
.. _`why pytest_pyfuncarg__ methods?`:
|
|
|
|
Why the ``pytest_funcarg__*`` name for funcarg factories?
|
|
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
|
|
|
We alternatively implemented an explicit registration mechanism for
|
|
function argument factories. But lacking a good use case for this
|
|
indirection and flexibility we decided to go for `Convention over
|
|
Configuration`_ and rather have factories specified by convention.
|
|
Besides removing the need for an registration indirection it allows to
|
|
"grep" for ``pytest_funcarg__MYARG`` and will safely find all factory
|
|
functions for the ``MYARG`` function argument.
|
|
|
|
.. _`Convention over Configuration`: http://en.wikipedia.org/wiki/Convention_over_Configuration
|
|
|
|
Can I yield multiple values from a funcarg factory function?
|
|
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
|
|
|
There are two conceptual reasons why yielding from a factory function
|
|
is not possible:
|
|
|
|
* Calling factories for obtaining test function arguments
|
|
is part of setting up and running a test. At that
|
|
point it is not possible to add new test calls to
|
|
the test collection anymore.
|
|
|
|
* If multiple factories yielded values there would
|
|
be no natural place to determine the combination
|
|
policy - in real-world examples some combinations
|
|
often should not run.
|
|
|
|
Use the `pytest_generate_tests`_ hook to solve both issues
|
|
and implement the `parametrization scheme of your choice`_.
|
|
|
|
.. _`pytest_generate_tests`: test/funcargs.html#parametrizing-tests
|
|
.. _`parametrization scheme of your choice`: http://tetamap.wordpress.com/2009/05/13/parametrizing-python-tests-generalized/
|
|
|
|
py.test interaction with other packages
|
|
---------------------------------------------------
|
|
|
|
Issues with py.test, multiprocess and setuptools?
|
|
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
|
|
|
On windows the multiprocess package will instantiate sub processes
|
|
by pickling and thus implicitly re-import a lot of local modules.
|
|
Unfortunately, setuptools-0.6.11 does not ``if __name__=='__main__'``
|
|
protect its generated command line script. This leads to infinite
|
|
recursion when running a test that instantiates Processes.
|
|
|
|
A good solution is to `install Distribute`_ as a drop-in replacement
|
|
for setuptools and then re-install ``pytest``. Otherwise you could
|
|
fix the script that is created by setuptools by inserting an
|
|
``if __name__ == '__main__'``. Or you can create a "pytest.py"
|
|
script with this content and invoke that with the python version::
|
|
|
|
import pytest
|
|
if __name__ == '__main__':
|
|
pytest.main()
|
|
|
|
.. _`install distribute`: http://pypi.python.org/pypi/distribute#installation-instructions
|
|
|
|
.. include:: links.inc
|