Mailman 3 April 2011 - pytest-dev

[py-dev] migration from 1.3 to 2.0
by Vyacheslav Rafalskiy June 1, 2011

June 1, 2011

Hi Holger and list members, I have been using py.test for some time after switching from nose and quite happy with it. However, when migrating from 1.3.1 to 2.0.2 I hit a couple of snags, which makes me hesitate. Perhaps you can help me. 1. Just to clear the point. I understand from another post that option_xxxx variables in conftest.py are gone and recommended replacement is to use pytest_cmdline_preparse(). Is that so? 2. The new behavior is that even if you run py.test --help, the pytest_configure() is still run. In my case pytest_configure() does quite a bit of heavy lifting and raises exceptions at wrong parameters. The result is that if the parameter is wrong I cannot use help to find out what is the right parameter. Of course, the workaround could be: def pytest_configure(config): if config.getvalue('help'): return ... but it seems ugly. Am I in a wrong hook? 3. In my pytest_configure() there are numerous conditions when it can fail. For this conditions I have exceptions with specially crafted messages, intended for different people. Now they are gone, replaced by a long and scary listing with every line prepended with INTERNALERROR. What is internal about it? Can I continue managing my configuration errors? Thanks, Vyacheslav

2 13

[py-dev] [ANN] plugin: pytest-incremental
by Eduardo Schettino May 6, 2011

May 6, 2011

Hi all, I have just pushed a new pytest plugin to pypi (http://pypi.python.org/pypi/pytest-incremental). The idea is to execute your tests faster by executing not all of them but only the "required" ones. This is very new (alpha), feedback is welcome :) Regards, Eduardo +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ pytest-incremental ==================== an incremental test runner (pytest plugin) What is an "incremental test runner" ? ======================================= When talking about build-tools it is common to refer to the terms: * initial (full) build - all files are compiled * incremental build (or partial rebuild) - just changed files are compiled * no-op build - no files are compiled (none changed since last execution) So an "incremental test runner" will only re-execute tests that were affected by changes in the source code since last test execution. How it works ? ================ `pytest-incremental` is a `pytest <http://pytest.org/>`_ plugin. So if you can run your test suite with pytest you can use `pytest-incremental`. The plugin will analyse your python source files and through its imports define the dependencies of the modules. `doit <http://python-doit.sourceforge.net>`_ is used to keep track of the dependencies and save results. The plugin will modify how pytest collect your tests. pytest do the rest of the job of actually running the tests and reporting the results. Install ========= pytest-incremental is tested on python 2.6, 2.7. ``pip install pytest-incremental``` ``python setup.py install`` local installation -------------------- You can also just grab the plugin `module <https://bitbucket.org/schettino72/pytest-incremental/src/tip/pytest_increme…>`_ file and put in your project path. Then enable it (check `pytest docs <http://pytest.org/plugins.html#requiring-loading-plugins-in-a-test-module-o…>`_). Usage ====== Just pass the parameter ``--incremental`` when calling from the command line:: $ py.test --incremental You can also enable it by default adding the following line to your ``pytest.ini``:: [pytest] addopts = --incremental watched packages ------------------ By default all modules collected by pytest will used as dependencies if imported. In order to limit or extend the watched folders you must use the parameter ``--watch-pkg`` Limitations ============== ``pytest-incremental`` looks for imports recursively to find dependencies (using AST). But given the very dynamic nature of python there are still some cases that a module can be affected by a module that are not detected. * `from package import *` modules imported from __all__ in a package are not counted as a dependency * modules imported not using the *import* statement * modules not explictitly imported but used at runtime (i.e. conftest.py when running your tests with pytest) * monkey-patching. (i.e. A imports X. B monkey-patches X. In this case A might depend on B) * others ? Project Details =============== - Project code + issue track on `bitbucket <https://bitbucket.org/schettino72/pytest-incremental>`_ - `Discussion group <http://groups.google.co.in/group/python-doit>`_

4 7

[py-dev] Help understanding pytest_generate_tests related error message
by Baptiste Lepilleur May 1, 2011

May 1, 2011

Hi, I just upgraded from py.test 1.3.4 to 2.0.3, and I'm running into a new failure related to pytest_generate_tests that I can not make sense of: --- py.test src\nitroz\test_dbo2.py ================================================= test session starts ================================================= platform win32 -- Python 3.2.0 -- pytest-2.0.3 collected 0 items / 1 errors ======================================================= ERRORS ======================================================== ______________________________________ ERROR collecting src/nitroz/test_dbo2.py _______________________________________ src\nitroz\test_dbo2.py:151: in pytest_generate_tests > good_value=good_value) ) C:\Python32\lib\site-packages\pytest-2.0.3-py3.2.egg\_pytest\python.py:550: in addcall > pytest.fail("funcarg %r not used in this function." % name) E Failed: funcarg 'property' not used in this function. =============================================== 1 error in 0.12 seconds =============================================== --- What does this error message means? What 'this function' refer to? Source of the test module can be found there: http://pastebin.com/1D2VArGt Baptiste.

2 6

[py-dev] initial take at a generic funcags hook
by Ronny Pfannschmidt April 29, 2011

April 29, 2011

hi, i just tried a initial implementation of generic funcargs to solve the issue i introduced the hook pytest_reconfigure_funcargs(request) the current patch is at https://bitbucket.org/RonnyPfannschmidt/pytest-patches/qseries?apply=t&qs_a… regards, Ronny

2 2

[py-dev] Empty traceback reported after running tests
by Baptiste Lepilleur April 28, 2011

April 28, 2011

Hi, I'm running into the following odd output when running some tests: --- py.test --nomagic mphelpertest.py ================================================= test session starts ================================================= platform win32 -- Python 3.2.0 -- pytest-1.3.4 test path 1: mphelpertest.py mphelpertest.py ... ============================================== 3 passed in 1.16 seconds =============================================== Traceback (most recent call last): --- Notes that the traceback is empty. Any idea of what could explain that? The test is installing and (hopefully) uninstalling some logging handler and use the multiprocessing module, so it may be possible that some exceptions are thrown on shutdown when logging handler are closed (but I have not yet managed to reproduce the issue outside py.test). Sources are available here: http://gaiacrtn.free.fr/temp/pytestmp/ Baptiste.

2 6

[py-dev] pytest-2.0.3: bug fixes and speed ups
by holger krekel April 17, 2011

April 17, 2011

py.test 2.0.3: bug fixes and speed ups =========================================================================== Welcome to pytest-2.0.3, a maintenance and bug fix release of pytest, a mature testing tool for Python, supporting CPython 2.4-3.2, Jython and latest PyPy interpreters. See the extensive docs with tested examples here: http://pytest.org/ If you want to install or upgrade pytest, just type one of:: pip install -U pytest # or easy_install -U pytest There also is a bugfix release 1.6 of pytest-xdist, the plugin that enables seemless distributed and "looponfail" testing for Python. best, holger krekel Changes between 2.0.2 and 2.0.3 ---------------------------------------------- - fix issue38: nicer tracebacks on calls to hooks, particularly early configure/sessionstart ones - fix missing skip reason/meta information in junitxml files, reported via http://lists.idyll.org/pipermail/testing-in-python/2011-March/003928.html - fix issue34: avoid collection failure with "test" prefixed classes deriving from object. - don't require zlib (and other libs) for genscript plugin without --genscript actually being used. - speed up skips (by not doing a full traceback represenation internally) - fix issue37: avoid invalid characters in junitxml's output

1 0

[py-dev] Creating unicode strings in pytest testsuit
by Floris Bruynooghe April 17, 2011

April 17, 2011

Hi While working on the patch for the invalid unicode codepoints in the junitxml output I discovered it's fairly hard to create a unicode strings in the the test suite. Currently I decided to use py.builtins._totext() to replace unicode string literals. And to get access to the unichr() builtin I've done this little hack: def foo(): global unichr try: unichr(65) except NameError: unichr = chr I think both are fairly fine, though am surprised by the leading underscore in _totext(), I'd have rather expected a py.builtin.unicode() name or so. And if the unichr hack is acceptable would it be worth to create py.builtins.unichr()? Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org

2 3

[py-dev] KeyError in xdist/looponfail.py
by schmir＠gmail.com April 14, 2011

April 14, 2011

py.test --looponfail did fail with the following traceback: ####################################### waiting for changes ######################################## ### Watching: /home/ralf/bbot/py-nextbot/nextbot/core Traceback (most recent call last): File "/home/ralf/local/bin/py.test", line 9, in <module> load_entry_point('pytest==2.0.2', 'console_scripts', 'py.test')() File "/home/ralf/local/lib/python2.7/site-packages/_pytest/core.py", line 448, in main exitstatus = hook.pytest_cmdline_main(config=config) File "/home/ralf/local/lib/python2.7/site-packages/_pytest/core.py", line 402, in __call__ return self._docall(methods, kwargs) File "/home/ralf/local/lib/python2.7/site-packages/_pytest/core.py", line 413, in _docall res = mc.execute() File "/home/ralf/local/lib/python2.7/site-packages/_pytest/core.py", line 331, in execute res = method(**kwargs) File "/home/ralf/local/lib/python2.7/site-packages/xdist/plugin.py", line 56, in pytest_cmdline_main looponfail_main(config) File "/home/ralf/local/lib/python2.7/site-packages/xdist/looponfail.py", line 26, in looponfail_main statrecorder.waitonchange(checkinterval=2.0) File "/home/ralf/local/lib/python2.7/site-packages/xdist/looponfail.py", line 195, in waitonchange changed = self.check() File "/home/ralf/local/lib/python2.7/site-packages/xdist/looponfail.py", line 213, in check del statcache[path] KeyError: local('/home/ralf/bbot/py-nextbot/nextbot/core/searchproc_flymake.py') I'm using flymake in emacs, and searchproc_flymake.py is a temporary file generated by flymake. cheers, -- ralf

3 3

[py-dev] the concept of a per test "test dir" and its uses
by Ronny Pfannschmidt April 13, 2011

April 13, 2011

hi, after some thought i would like to discuss adding a generic testdir, so for each test different plugins could store data/metadata currently only the tempdir plugin creates a session dir on first use of the tmpdir funcarg/pytest.mktemp i'd rather have to possibility to store for each test * full test id * stdout/err * logfile for stdlib logging * tmpdir for plugin * some kind of serialized full taceback, optionally with some locals/globals * coverage reports * profiler reports since all of those are a misfit for the tmpdir functionality, i'd like to propose a extension of the mechanism the basic tmpdir would move to the "tmpdir" subdir of the testdir, stdout/err, log, would in turn be files in the testdir it would also be easily possible to keep those in sync with xdist+rsync should the need arise, just make a new testdir for the remote id, and sync the directory content. further possible uses include using coverage data and test results of previous runs to decide what tests can likely be skipped without causing too much of a problem or providing relative progress information on the collection status (based on the number of test id's in the last run). Please discuss additional uses and possible problems. Regards Ronny

2 1

[py-dev] latest pytest questions for pytest-cov
by meme dough April 6, 2011

April 6, 2011

Hi, Currently looking at fixing pytest-cov to work with latest pytest. I see two issues so far. 1. How to determine if non distributed, or distributed master, or distributed slave. This used to look at the session class Session = Central (non distributed), DSession = distributed master, and SlaveSession = distributed slave. So now I'm thinking look at session.config.pluginmanager.hasplugin('dsession') which means distributed master. For distributed slave check if config.slaveinput is there which means distributed slave. If none of those then must be non distributed. Is there a better way to determine at pytest_sessionstart if the process is central (non distributed), distributed master or distributed slave? 2. Need to know topdir. This used to use config.topdir to know what the root dir is. This is needed since distributed testing may be co-located or not. If not then have to rewrite all source paths back to what the master is set to so that all coverage files combine correctly even if have many separate tx envs on diff machines on diff paths. Has this moved somewhere? I see config.fspath, is that it? I look more I just got to this bit. :)

2 3