Frequent Issues and Questions ================================== .. _`installation issues`: Installation issues ------------------------------ easy_install or pip not found? ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Consult distribute_ to install the ``easy_install`` tool on your machine. You may also use the original but somewhat older `setuptools`_ project although we generally recommend to use ``distribute`` because it contains more bug fixes and also works for Python3. For Python2 you can also consult pip_ for the popular ``pip`` tool. for the according ``pip`` installation tool. installation instructions. You can also `setuptools`_ and If you want to install on Python3 you need to use Distribute_ which provides the ``easy_install`` utility. py.test not found on Windows despite installation? ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .. _`Python for Windows`: http://www.imladris.com/Scripts/PythonForWindows.html - **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 ------------------------------------------------ Why the ``py.test`` naming, why not ``pytest``? ++++++++++++++++++++++++++++++++++++++++++++++++++ XXX because of TAB-completion under Bash/Shells. If you hit ``py.`` you'll get a list of available development tools that all share the ``py.`` prefix. Another motivation was to unify the package ("py.test") and tool filename. What's py.test's relation to ``nosetests``? +++++++++++++++++++++++++++++++++++++++++++++++++ py.test and nose_ share basic philosophy when it comes to running Python tests. In fact, with py.test-1.1.0 it is ever easier to run many test suites that currently work with ``nosetests``. nose_ was created as a clone of ``py.test`` when py.test was in the ``0.8`` release cycle so some of the newer features_ introduced with py.test-1.0 and py.test-1.1 have no counterpart in nose_. .. _nose: http://somethingaboutorange.com/mrl/projects/nose/0.11.1/ .. _features: test/features.html .. _apipkg: http://pypi.python.org/pypi/apipkg What's this "magic" with py.test? ++++++++++++++++++++++++++++++++++++++++++ Around 2007 it was claimed that py.test was magic implementation wise XXX. It has been refactored. * 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-intepretation. 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-based setup a style question? +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ XXX For simple applications and for people experienced with nose_ or unittest-style test setup using `xUnit style setup`_ feels natural. For larger test suites, parametrized testing or setup of complex test resources using funcargs_ is recommended. 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 .. _`xUnit style setup`: test/xunit_setup.html .. _`pytest_nose`: test/plugin/nose.html .. _`why pytest_pyfuncarg__ methods?`: Why the ``pytest_funcarg__*`` name for funcarg factories? ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ When experimenting with funcargs an explicit registration mechanism was considered. But lacking a good use case for this indirection and flexibility we decided to go for `Convention over Configuration`_ and allow to directly specify the factory. Besides removing the need for an indirection it allows to "grep" for ``pytest_funcarg__MYARG`` and will safely find all factory functions for the ``MYARG`` function argument. It helps to alleviate the de-coupling of function argument usage and creation. .. _`Convention over Configuration`: http://en.wikipedia.org/wiki/Convention_over_Configuration Can I yield multiple values from a 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 implicitely re-import a lot of local modules. Unfortuantely, 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. There are these workarounds: * `install Distribute`_ as a drop-in replacement for setuptools and install py.test * `directly use a checkout`_ which avoids all setuptools/Distribute installation If those options are not available to you, you may also manually 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 py if __name__ == '__main__': py.cmdline.pytest() .. _`directly use a checkout`: install.html#directly-use-a-checkout .. _`install distribute`: http://pypi.python.org/pypi/distribute#installation-instructions