Mailman 3 August 2015 - pytest-dev

Releases
by Florian Bruhin Sept. 17, 2015

Sept. 17, 2015

Hi! We've been talking about doing a release since somewhen before EuroPython and there's still no release with Python 3.5 support out yet ;) What's missing for a 2.7.3, and what for 2.8.0? Does it make sense to release 2.7.3, or should we go for 2.8.0 directly? Looking at the changelog, 2.8 has some bugfixes as well (I'm guilty on that one), so I wonder if we should just release that directly (and when). Either way, both have features/fixes I'm eagerly waiting for, and enough changes to warrant a release IMHO. Florian -- http://www.the-compiler.org | me(a)the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/

4 16

Working with other dependency injection systems
by Kai Groner Sept. 10, 2015

Sept. 10, 2015

Hi testing people! I'm trying to figure out how I can test a code base that uses an existing dependency injection system. I've run into two problems, and I have solutions for each of them but I think maybe there is a better way, so I'm looking for some advice. The first problem is how do I override how a test using this injector is called? I think I want to use the pytest_runtest_call hook, but it still tries to invoke the test without the injector. My current solution is to use the experimental hookwrapper mechanism to replace item.obj with a partially bound version, then restore it afterward. The second problem I'm having is the py.test fixture system is trying to resolve arguments that are provided by this other injector. How can I tell it that some of these don't need to be provided? My current solution is to blind py.test with a wrapper function with a *a, **kw signature. I use functools.wraps, so annotations are introspectable for the other injector, and delete the __wrapped__ attribute to prevent py.test from introspecting it. Is there a nicer, and perhaps less blunt, way to influence the funcarg fixture behaviors? I've tried a couple things with the pytest_collection_modifyitems hook, but haven't gotten anything that works yet. Other details to know about this injection system: - we want to build and teardown the injector with each test - we may want to configure the injector differently for some tests (possibly with fixture data from py.test) Thanks, Kai

2 6

Vendoring pluggy with pytest
by Florian Bruhin Sept. 5, 2015

Sept. 5, 2015

Hi! I'm part of the pytest-dev team, the developers of the pytest[1] test runner. I'm writing to you because I'd like to have some opinions on the following PR/issue about vendoring pluggy into pytest: https://github.com/pytest-dev/pytest/issues/944 https://github.com/pytest-dev/pytest/pull/959 The common logic behind the plugin API of pytest recently got split into a separate library, pluggy[2]. However, the public API of pluggy might still change in the near future - which means pytest would need to require a specific version of pluggy to be sure there's no breakage. Normally, this wouldn't be an issue - but as a test runner, I believe we're in a bit of a special position: Users should still be able to use pytest to test their projects, even if their projects use a more recent version of pluggy - or they use other projects which might use pluggy in the future, like devpi or tox. Because of this, since it's a very small library, and because the code originated from pytest, I wonder what distribution's views are on bundling the library for pytest 2.8 until things are expected to be a bit more stable. What do you think? Florian [1] http://www.pytest.org/ [2] https://github.com/hpk42/pluggy -- http://www.the-compiler.org | me(a)the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/

2 1

pytest-xdist 1.13 release
by Ronny Pfannschmidt Aug. 18, 2015

Aug. 18, 2015

Hello, i'm pleased to announce the release of pytest-xdist 1.13 changes to 1.2 are: - extended the tox matrix with the supported py.test versions - split up the plugin into 3 plugin's to prepare the departure of boxed and looponfail. looponfail will be a part of core and forked boxed will be replaced with a more reliable primitive based on xdist - conforming with new pytest-2.8 behavior of returning non-zero when all tests were skipped or deselected. - new "--max-slave-restart" option that can be used to control maximum number of times pytest-xdist can restart slaves due to crashes. Thanks to Anatoly Bubenkov for the report and Bruno Oliveira for the PR. - release as wheel - "-n" option now can be set to "auto" for automatic detection of number of cpus in the host system. Thanks Suloev Dmitry for the PR. -- Ronny

1 0

Can we get a pytest-timeout release?
by Wolfgang Schnerring Aug. 15, 2015

Aug. 15, 2015

Hi, the PR https://bitbucket.org/flub/pytest-timeout/pull-requests/3 has been merged on 2014-09-23, is there chance someone could make a release of this? I'm eagerly awaiting it, and cursing each time the timeout kills my hard-earned pdb session... Thanks, Wolfgang

2 3

Could we get a pytest-timeout release?
by Wolfgang Schnerring Aug. 13, 2015

Aug. 13, 2015

Hi, the PR https://bitbucket.org/flub/pytest-timeout/pull-requests/3 has been merged on 2014-09-23, so... any chance this could be released? I'm eagerly awaiting this, and curse each time the timeout kills my pdb session... Thanks, Wolfgang

1 0

[ANN] pytest-ignore-flaky plugin 0.1.0
by Eduardo Schettino Aug. 11, 2015

Aug. 11, 2015

Hi, I just published a new plugin to hadle flaky tests: https://pypi.python.org/pypi/pytest-ignore-flaky https://github.com/schettino72/pytest-ignore-flaky feedback welcome cheers, Eduardo pytest-ignore-flaky ==================== ignore failures from flaky tests (pytest plugin) A "flaky" test is a test that usually pass but sometimes it fails. You should always avoid flaky tests but not always possible. This plugin can be used to optionally ignore failures from flaky tests. First "mark" your tests with the `flaky` marker:: import random import pytest @pytest.mark.flaky def test_mf(): assert 0 == random.randint(0, 1) By default this mark is just ignored, unless the plugin is activated from the command line (or `py.test` config file):: py.test --ignore-flaky If a flaky test pass it will be reported normally as test succeed. If the test fails, instead of being reported as failure it will be reported as a `xfail`.

1 0

Cheeseshop (PyPI) access
by Floris Bruynooghe Aug. 9, 2015

Aug. 9, 2015

Hi all, As discussed at EuroPython I was looking at giving everyone in the pytest-dev groups on bitbucket and github access on the cheeseshop (pypi) to be able to do releases. Currently I only know the following cheeseshop usernames however: hpk ronny flub nicoddemus anatoly So could other people in pytest-dev on either bitbucket or github please let me know their usernames? Preferably gpg signed and/or encrypted if possible [0][1], but don't worry too much if not. Additionally I only have the permissions to do this on the following packages: pytest pytest-xdist pytest-timeout (not yet in pytest-dev but it really should be ;-)) In particular I'm missing access to py :-) Could owners of other repos enable other people as well if they agree? Or if you can't be bothered to do this currently very manual task for everyone just give me permissions and tell me to add the full list of people and I'll patiently go through the list. Regards, Floris [0] My key is 4CCB3FFC, as signed [1] I also have keybase.io invites if you'd like some form of verification. Keybase provides an easy way to "prove" a particular private key can control a particular github account, which has it's use [2]. [2] Not that this couldn't be done manually, but everyone is bad with manually doing things as proven by after having met Holger a few times in real life we still haven't verified our keys despite using them sometimes in email. Ah, gpg.

3 3

Flaky tests
by Anatoly Bubenkov Aug. 9, 2015

Aug. 9, 2015

Hi all, flaky tests are often really hard to make not flaky, so I've got the idea to just retry failed tests several times automatically and only then report the failure. I was not the only one of course: there's nice initiative in face of https://github.com/box/flaky The big downside of that plugin's approach, is that only 'call' phase is retried, while 'setup' is not re-executed and so all function-scoped fixtures stay as is from previous try. This is not acceptable if you use fixtures intensively of course. I created an issue where I have a snippet how it could work https://github.com/box/flaky/issues/53 But then realized that it doesn't work properly still: when it's the only test collected which we're going to retry, all fixtures, including session-scoped are being resetup as well! Then looked more and couldn't find any good solutions to actually very simple question: how do i rerun the test in the same test run? Any help is appreciated. I think making that plugin work or even making it available in the core would be a great improvement. Thanks!

3 3

devpi channel for Travis CI testing of pytest-dev/pytest
by Bruno Oliveira Aug. 5, 2015

Aug. 5, 2015

Hi everyone, Currently we use Holger's private channel (https://devpi.net/hpk/dev) to obtain packages for testing on Travis. How about if we create a "pytest-dev" user on devpi.net which would be the official package source for continuous integration of pytest-dev/pytest? This would allow other contributors to fix CI-related problems (like recently experienced with flakes in https://github.com/pytest-dev/pytest/pull/897). I just noticed that AppVeyor obtains the packages directly from pip... I think this is an oversight, correct? Cheers,

2 1