Mailman 3 February 2011 - pytest-dev

[py-dev] py.test doctest and hooks...
by Christian Klinger March 14, 2011

March 14, 2011

Hello, are there any hooks in pytest which are executed before doctests are executed? I try to setup some stuff, which i want to hide in the doctest. I already tried some "normal" pytest hooks ala: - pytest_runtest_call(item):- pytest_runtest_setup(item): But none of them seems to be executed on doctest execution. Any ideas? Christian

2 3

Re: [py-dev] New issue 1 in pytest-cov: Allow branch coverage
by meme dough Feb. 26, 2011

Feb. 26, 2011

Hi, I'm cross posting to pytest and coverage to discuss. At the start pytest-cov had command line options to control all of coverage. Talk on pytest mailing list there was concern about so many options and that it should have minimal options. That way py.test --help output is shorter and more useful as a single plugin doesn't output huge amounts of text hiding the other plugin help text. Also it could be fully controlled through coverage config file. We could add a small number of options in but I'd like to get others opinions first. Plus how do we decide which ones should be in or not. If we add branch then maybe someone else wants timid or cover pylib. Another thing to consider is should coverage have env vars for all of it's options. That way it could be controlled from the command line but independent of the test runner (pytest, nose, unittest2) and so it would work with all of them. Something like: {{{ COVERAGE_BRANCH=1 py.test --cov-report term-missing --cov myproj tests/ }}} Or the following as coverage already reads COVERAGE_OPTIONS to get timid option: {{{ COVERAGE_OPTIONS="--branch" py.test --cov-report term-missing --cov myproj tests/ }}} These days I quite like the minimal options with full control through config file. But I do see that it is nice to control through the command line which is why I had full control of every option at the very beginning (in fact I had command line option, env var, then config file for each option). Any ideas on leaving it as it is? Adding small number of options to pytest-cov? Adding env vars to coverage to control independently so works will all test runners? :) On 26 February 2011 08:36, Bitbucket <issues-noreply(a)bitbucket.org> wrote: > --- you can reply above this line --- > > New issue 1: Allow branch coverage > https://bitbucket.org/memedough/pytest-cov/issue/1/allow-branch-coverage > > jimslack on Fri, 25 Feb 2011 22:36:33 +0100: > > Description: > I know it is possible to activate branch coverage using a config file, but I'd like to use branch coverage with a command-line option. Perhaps something like: > > {{{ > py.test --cov-report term-missing --cov --branch myproj tests/ > }}} > > or > > {{{ > py.test --cov-report term-missing --covbranch myproj tests/ > }}} > > Another possibility would be to make branch coverage the default. > > Thanks. > > > > > -- > > This is an issue notification from bitbucket.org. You are receiving > this either because you are the owner of the issue, or you are > following the issue. >

1 0

[py-dev] New plugin: pytest-monkeyplus
by Virgil Dupras Feb. 16, 2011

Feb. 16, 2011

Hi there, A few weeks ago I talked about the possibility of adding helpers to the monkeypatch module. Today, I'm publishing a new plugin which I called "monkeyplus" to test the water with these new helpers (patch_osstat, patch_today). Repository is at https://bitbucket.org/hsoft/pytest-monkeyplus Virgil Dupras

2 1

[py-dev] anybody up for a pytest.org typo-fixing review?
by holger krekel Feb. 15, 2011

Feb. 15, 2011

Hi all, i realize there are a number of typos and bugs at the http://pytest.org documentation which is sphinx-based. Would someone maybe like to help and go through some files and send me a patch? If so just do a hg clone https://hpk42@bitbucket.org/hpk42/pytest send me a diff or fork it on BB and notify me. I am also happy to fix paragraphs that are unclear if pointed to it. thanks, holger

1 0

[py-dev] pytest-2.0.1: bug fixes and better asserts
by holger krekel Feb. 7, 2011

Feb. 7, 2011

py.test 2.0.1: bug fixes and better asserts =========================================================================== Welcome to pytest-2.0.1, 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 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 Many thanks to all issue reporters and people asking questions or complaining. Particular thanks to Floris Bruynooghe and Ronny Pfannschmidt for their great coding contributions and many others for feedback and help. best, holger krekel Changes between 2.0.0 and 2.0.1 ---------------------------------------------- - refine and unify initial capturing so that it works nicely even if the logging module is used on an early-loaded conftest.py file or plugin. - fix issue12 - show plugin versions with "--version" and "--traceconfig" and also document how to add extra information to reporting test header - fix issue17 (import-* reporting issue on python3) by requiring py>1.4.0 (1.4.1 is going to include it) - fix issue10 (numpy arrays truth checking) by refining assertion interpretation in py lib - fix issue15: make nose compatibility tests compatible with python3 (now that nose-1.0 supports python3) - remove somewhat surprising "same-conftest" detection because it ignores conftest.py when they appear in several subdirs. - improve assertions ("not in"), thanks Floris Bruynooghe - improve behaviour/warnings when running on top of "python -OO" (assertions and docstrings are turned off, leading to potential false positives) - introduce a pytest_cmdline_processargs(args) hook to allow dynamic computation of command line arguments. This fixes a regression because py.test prior to 2.0 allowed to set command line options from conftest.py files which so far pytest-2.0 only allowed from ini-files now. - fix issue7: assert failures in doctest modules. unexpected failures in doctests will not generally show nicer, i.e. within the doctest failing context. - fix issue9: setup/teardown functions for an xfail-marked test will report as xfail if they fail but report as normally passing (not xpassing) if they succeed. This only is true for "direct" setup/teardown invocations because teardown_class/ teardown_module cannot closely relate to a single test. - fix issue14: no logging errors at process exit - refinements to "collecting" output on non-ttys - refine internal plugin registration and --traceconfig output - introduce a mechanism to prevent/unregister plugins from the command line, see http://pytest.org/plugins.html#cmdunregister - activate resultlog plugin by default - fix regression wrt yielded tests which due to the collection-before-running semantics were not setup as with pytest 1.3.4. Note, however, that the recommended and much cleaner way to do test parametraization remains the "pytest_generate_tests" mechanism, see the docs.

1 0