This mostly has historic reasons - the aim is to get away from the somewhat questionable ‘py’ name at some point. These days (2010) the ‘py’ library almost completely comprises APIs that are used by the py.test tool. There also are some other uses, e.g. of the py.path.local() and other path implementations. So it requires some work to factor them out and do the shift.
because of TAB-completion under Bash/Shells. If you hit py.<TAB> 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.
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.
issues where people have used the term “magic” in the past:
You can issue:
py.test --version
which tells you both version and import location of the tool.
It depends. For simple applications or for people experienced with nose or unittest-style test setup using xUnit style setup make some sense. 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.
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.
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. There are these workarounds:
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()