
Some Issues and Questions
*************************

Note: If you don't find an answer here, you may checkout pytest Q&A at
  Stackoverflow or other *Contact channels* to get help.


On naming, nosetests, licensing and magic
=========================================


How does py.test relate to nose and unittest?
---------------------------------------------

py.test and nose share basic philosophy when it comes to running and
writing Python tests.  In fact, you can run many tests written for
nose with py.test.  nose was originally created as a clone of
"py.test" when py.test was in the "0.8" release cycle.  Note that
starting with pytest-2.0 support for running unittest test suites is
majorly improved.


how does py.test relate to twisted's trial?
-------------------------------------------

Since some time py.test has builtin support for supporting tests
written using trial. It does not itself start a reactor, however, and
does not handle Deferreds returned from a test in pytest style. If you
are using trial's unittest.TestCase chances are that you can just run
your tests even if you return Deferreds.  In addition, there also is a
dedicated pytest-twisted plugin which allows to return deferreds from
pytest-style tests, allowing to use *pytest fixtures: explicit,
modular, scalable* and other features.


how does py.test work with Django?
----------------------------------

In 2012, some work is going into the pytest-django plugin.  It
substitutes the usage of Django's "manage.py test" and allows to use
all pytest features most of which are not available from Django
directly.


What's this "magic" with py.test? (historic notes)
--------------------------------------------------

Around 2007 (version "0.8") some people thought that py.test was using
too much "magic".  It had been part of the pylib which contains a lot
of unreleated python library code.  Around 2010 there was a major
cleanup refactoring, which removed unused or deprecated code and
resulted in the new "pytest" PyPI package which strictly contains only
test-related code.  This relese also brought a complete
pluginification such that the core is around 300 lines of code and
everything else is implemented in plugins.  Thus "pytest" today is a
small, universally runnable and customizable testing framework for
Python.   Note, however, that "pytest" uses metaprogramming techniques
and reading its source is thus likely not something for Python
beginners.

A second "magic" issue was the assert statement debugging feature.
Nowadays, py.test explicitely rewrites assert statements in test
modules in order to provide more useful *assert feedback*. This
completely avoids previous issues of confusing assertion-reporting. It
also means, that you can use Python's "-O" optimization without
loosing assertions in test modules.

py.test contains a second mostly obsolete assert debugging technique,
invoked via "--assert=reinterpret", activated by default on
Python-2.5: When an "assert" statement fails, py.test re-interprets
the expression part to show intermediate values.  This technique
suffers from a caveat that the rewriting does not: If your expression
has side effects (better to avoid them anyway!) the intermediate
values may not be the same, confusing the reinterpreter and
obfuscating the initial error (this is also explained at the command
line if it happens).

You can also turn off all assertion interaction using the "--
assertmode=off" option.


Why a "py.test" instead of a "pytest" command?
----------------------------------------------

Some of the reasons are historic, others are practical.  "py.test"
used to be part of the "py" package which provided several developer
utilities, all starting with "py.<TAB>", thus 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 since many people have gotten used to the old name
and there is another tool named "pytest" we just decided to stick with
"py.test" for now.


Function arguments, parametrized tests and setup
================================================


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 probably 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.


Why the "pytest_funcarg__*" name for funcarg factories?
-------------------------------------------------------

We like Convention over Configuration and didn't see much point in
allowing a more flexible or abstract mechanism.  Moreover, it is nice
to be able to search for "pytest_funcarg__MYARG" in source code and
safely find all factory functions for the "MYARG" function argument.

Note: With pytest-2.3 you can use the *Fixtures as Function arguments
  (funcargs)* decorator to mark a function as a fixture function.


Can I yield multiple values from a fixture function 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.

However, with pytest-2.3 you can use the *Fixtures as Function
arguments (funcargs)* decorator and specify "params" so that all tests
depending on the factory-created resource will run multiple times with
different parameters.

You can also use the pytest_generate_tests hook to implement the
parametrization scheme of your choice.


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()
