Mailman 3 August 2009 - pytest-dev

[py-dev] py.test : setup / teardown at the directory level
by Philippe Fremy April 16, 2010

April 16, 2010

Hi, I was wondering if there is a possibility to have or emulate setup/teardown method for an entire directory of tests ? I have an expensive setup/teardown method, which I share through about 10 modules, each with about 20 tests. I would save time if I could do the setup/teardown just for that directory. cheers, Philippe

3 9

[py-dev] using docstrings for test descriptions
by Frederik Dohr Sept. 9, 2009

Sept. 9, 2009

Hello all, Holger's presentations at EuroPython last week convinced me that I should finally start migrating to py.test. There's only one thing I'm missing: I'm used to providing fairly detailed descriptions for individual tests ("foo returns bar if baz"). While one could use the assert statement's second argument for this, that seems cumbersome and has some undesired side-effects (e.g. reporting "E AssertionError: <description>" instead of displaying the respective values). Docstrings appear to be the obvious (and pythonic) solution. So I imagine a plugin could add docstring support, which might result in output as described here: http://gist.github.com/141977 (Being new to py.test, it is possible my expectations are misguided - don't hesitate to point out where that's the case.) I'd be willing to look into how this might be implemented; it shouldn't be too hard (e.g. using a decorator), but some pointers on how to get started would be appreciated. Thanks, Fred

2 6

[py-dev] examples for programmatically running py.test and collecting the results in a custom way?
by Ronny Pfannschmidt Sept. 1, 2009

Sept. 1, 2009

hi, for the pida integration of py.test i could use some ideas on how to run it and how to iteratively collect the results./changes to the results for looponfail. Regards Ronny Pfannschmidt

2 2

[py-dev] 1.0.2 released / some 1.1 planning notes
by holger krekel Aug. 27, 2009

Aug. 27, 2009

Hi all, i just released a pylib/py.test 1.0.2 fixing a number of packaging issues, triggered by fedora packaging issues. I also added a link to the new pytest_django plugin. see the plugin index at http://pylib.org FYI i am currently refactoring and simplifying the code of pylib/py.test and aim for cleaned up mostly-compatible to 1.1 release next month: * featuring cpython 2.4 through to 3.1, jython + pypy compatilibty. * moving the tests out of the lib itself * introducing a way to specify what tests belong to a module/directory (see recent RFC mails) * relicensing to LGPL I'd also like to get the 1.1 flagged issues in the tracker resolved, see http://bitbucket.org/hpk42/py-trunk/issues/?status=new&status=open cheers, holger -- Metaprogramming, Python, Testing: http://tetamap.wordpress.com Python, PyPy, pytest contracting: http://merlinux.eu

1 0

[py-dev] outlining some of my needs for execnet + possible solutions
by Ronny Pfannschmidt Aug. 27, 2009

Aug. 27, 2009

Hi, i'd like to outline some needs i have for execnet as well as propossing some rough sketchouts of possible solution py.execnet between python2 and python3 -------------------------------------- This arises as i want to use anyvc in python3 while the backends are not portable to python3 yet. However syntax differences make normal interaction hard and will most likely perfectly destroy the zero install mechanisms. installing more complex dependencies in virtualenvs and reusing those --------------------------------------------------------------------- Syntax differences between python versions as well as complex package dependencies mandate installing some packages on the remote side. Tools like virtualenv help with installing those separate from the normal system as well as with limited rights. However those tools might need some bootstraping outside of python as the remote might not be ready to just start up a execnet slave. a simple remote object protocol via wrappers around channels ------------------------------------------------------------ Inventing own protocols on top of channels if one want's to controll remote-objects is a fragile task, helper classes to ease the process are very welcome. the proposed solutions ----------------------- 1. gw.remote_call(remote_callable, *k, **kw) as alternative to gw.remote_exec(code) * import the callable remote_callable on the remote * call remote_callable(channel, *k, **kw) where channel is the usual remote_channel 2. a virtualenv based minimal install system it needs to do without a usable remote python (ie wrong platform, whatever): * create a virtualenv at a given path * install something like a minimal py.execnet slave, so the remote side can be started * all other install operations should be controllable via some kind of remote_exec/remote_call 3. RemoteCaller/RemoteHandler as wrappers around channels that represent remote objects * a experiment in anyvc * currently lacks a way to propperly document remote methods * RemoteCaller is a base class for wrappers that call to remote objects via a channel object.method(*k, **kw) translates to channel.send(('method', k, kw)) return channel.receive() the default handling can be overridden by implementing own methods the method self._call_method(name, k, kw) ma * RemoteHandler is a base class for Channel callbacks once can use as convience wrapper around remote objects in order too ease handling messages for each incoming method, k, kw tuple it calls the method on self, unpacking the arguments

1 0

[py-dev] outlining what i intend to do with execnet + what additional features could be helpfull
by Ronny Pfannschmidt Aug. 24, 2009

Aug. 24, 2009

hi, first let me outline my needs for anyvc a vcs abstraction lib pida a ide based on the idea that everything is a plugin anyvc ------ * execute backends in a different process * circumvent gpl/gpl2only of hg/dulwich/bzr * execute the fontend on python platforms not supported by the backends * python 3 * jython * ironpython * pypy pida ---- an ide based on plugins * run parts of plugins in different processes * avoid gil races for cpu-intensive tasks * run parts of plugins on different computers/platforms * test execution * introspectiong of test/deployment environments * general work on remote data/projects In order to archieve those goals i think i need a few conceptual ideas for installing the different libs on the different platforms as well as a tool to help proxying method calls to remote objects. regards Ronny

2 3

[py-dev] 1.0.1 pylib/py.test: improved reporting, nose/unittest.py support, bug fixes
by holger krekel Aug. 19, 2009

Aug. 19, 2009

Hi all, pylib/py.test 1.0.1 is a bugfix release also coming with: * improved documentation, site navigation, configuration help * test failure reporting improvements * support for directly running existing nose/unittest.py style tests visit here for more info, including quickstart and tutorials: http://pytest.org and http://pylib.org have fun, holger Changelog 1.0.0 to 1.0.1 ------------------------ * added a default 'pytest_nose' plugin which handles nose.SkipTest, nose-style function/method/generator setup/teardown and tries to report functions correctly. * improved documentation, better navigation: see http://pytest.org * added a "--help-config" option to show conftest.py / ENV-var names for all longopt cmdline options, and some special conftest.py variables. renamed 'conf_capture' conftest setting to 'option_capture' accordingly. * unicode fixes: capturing and unicode writes to sys.stdout (through e.g a print statement) now work within tests, they are encoded as "utf8" by default, also terminalwriting was adapted and somewhat unified between windows and linux * fix issue #27: better reporting on non-collectable items given on commandline (e.g. pyc files) * fix issue #33: added --version flag (thanks Benjamin Peterson) * fix issue #32: adding support for "incomplete" paths to wcpath.status() * "Test" prefixed classes are *not* collected by default anymore if they have an __init__ method * monkeypatch setenv() now accepts a "prepend" parameter * improved reporting of collection error tracebacks * simplified multicall mechanism and plugin architecture, renamed some internal methods and argnames

1 0

[py-dev] building reusable testsuites
by Ronny Pfannschmidt Aug. 18, 2009

Aug. 18, 2009

Hi, while building the testsuite of anyvc i noticed i need a way to enable others to use my testsuite for backends on their own code in order to test/validate 3rd party backends. Right now i don't think its possible, please lets discuss possible solutions. Regards Ronny Pfannschmidt

2 1

[py-dev] specifying testfile patterns / RFC
by holger krekel Aug. 12, 2009

Aug. 12, 2009

Hi all, i am hacking on a new plugin to go into py.test-1.0.1 and i am doing that in documentation-driven style. So i am interested in feedback and comments on the below soon-to-become reality "pytest_testfiles" plugin. best & thanks, holger pytest_testfiles.py: determine test files for command line specified args. =========================================================================== usage example: specifying testfiles in a python module ----------------------------------------------------- If you have a module ``mymodule.py`` you can specify test files like this:: # content of: mymodule.py # relative paths __testfiles__ = ['test/test_unittest.py', 'test/test_functional.py'] and if you then type:: py.test mymodule.py then this will run the test files which were specified relatively to the directory of ``mymodule.py``. Ordering is significant: if you specify quick-running unit-tests first followed by slower running functional tests then issuing commands like ``py.test -x`` allows to find failures quickly and the easier-to-debug ones first. usage example: specifying project-specific testfile patterns -------------------------------------------------------------- Suppose your project has this layout:: app/ sub1/ module1.py tests/ unit/ test_module1.py functional/ test_one.py test_two.py you may specify filematching rules for finding tests like this:: # contents of: conftest.py conf_testfilepatterns = ["{topdir}/tests/unit/test_{basename}", "{topdir}/tests/functional/*.py"] and if you then type:: py.test app/sub1/module1.py the specified testfile patterns will be applied to check if there are matching test files. In our example we will run test files in the following order:: tests/unit/test_module.py tests/functional/test_one.py tests/functional/test_two.py default is to look for test files being close to code ---------------------------------------------------------- If no ``conf_testfilepatterns`` are specified, py.test will use this as a default setting:: conf_testfilepatterns = [ "*/test_{purebasename}.py", "**/test_*.py", "**/*_test.py" ] Note that each matching test file will only be run at most once. Substitutions ------------------- The following substitutions are performed for each file-or-directory command line argument:: dirname the dirname of the file basename basename of the file purebasename basename without the extension topdir first upwards parent directory not containing __init__.py

1 0

[py-dev] issues with stdout redirection, ctypes and py.test
by Gordon Wrigley Aug. 8, 2009

Aug. 8, 2009

My python code talks to a C library via ctypes and it in turn prints debug to stdout. And we test this with py.test, which by itself works just fine. But if at the bash prompt we then redirect the output of py.test to a file suddenly the C debug starts propagating out of py.test. We generally run py.test with -v and -x, but removing those didn't change the behavior at all. I'm at a bit of loss as to where to begin with this one, any suggestions? gordonw@gohma:~$ uname -a Linux gohma 2.6.28-14-generic #47-Ubuntu SMP Sat Jul 25 00:28:35 UTC 2009 i686 GNU/Linux gordonw@gohma:~$ python Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) [GCC 4.3.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import py >>> py.version '1.0.0' Regards, Gordon

2 5