Note
If you don’t find an answer here, checkout the Contact channels to get help.
Some historic, some practical reasons: py.test used to be part of the py package which provided several developer utitilities, 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 pytest but then many people have gotten used to the old name and there also is another tool with this same which would lead to some clashes.
py.test and nose share basic philosophy when it comes to running Python tests. In fact, you can run many tests written for unittest or nose with py.test. nose was originally created as a clone of py.test when py.test was in the 0.8 release cycle.
Around 2007 (version 0.8) some several people claimed that py.test was using too much “magic”. It has been refactored a lot. It is today probably one of the smallest, most universally runnable and most customizable testing frameworks for Python. It remains 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-intepretation. Sidenote: it is good practise to avoid asserts with side effects.
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.
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.
There are two conceptual reasons why yielding from a factory function is not possible:
Use the pytest_generate_tests hook to solve both issues and implement the parametrization scheme of your choice.
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.
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()