Mailman 3 January 2018 - pytest-dev

Alias to parametrize
by Bruno Oliveira Feb. 2, 2018

Feb. 2, 2018

Hi all, A PR[1] has been submitted which adds `parameterize` as an alias to `parametrize`. Florian Bruhin and I are not very keen to the idea given that there is an explicit warning for it already and having different names to the same thing reduces consistency across test suites. I'm sending an email here because I suppose more people read the mailing list than watch the PRs and the discussions there. It would be good if more people commented/voted on the issue before we reach a conclusion. [1] https://github.com/pytest-dev/pytest/pull/3159 Cheers

7 11

pytest 3.4.0 released!
by Bruno Oliveira Jan. 30, 2018

Jan. 30, 2018

The pytest team is proud to announce the 3.4.0 release! pytest is a mature Python testing tool with more than a 1600 tests against itself, passing on many different interpreters and platforms. This release contains considerable improvements to the logging facilities as well as other fixes and improvements, so users are encouraged to take a look at the CHANGELOG: http://doc.pytest.org/en/latest/changelog.html For complete documentation, please visit: http://docs.pytest.org As usual, you can upgrade from pypi via: pip install -U pytest Thanks to all who contributed to this release, among them: * Aaron * Alan Velasco * Anders Hovmöller * Andrew Toolan * Anthony Sottile * Aron Coyle * Brian Maissy * Bruno Oliveira * Cyrus Maden * Florian Bruhin * Henk-Jaap Wagenaar * Ian Lesperance * Jon Dufresne * Jurko Gospodnetić * Kate * Kimberly * Per A. Brodtkorb * Pierre-Alexandre Fonta * Raphael Castaneda * Ronny Pfannschmidt * ST John * Segev Finer * Thomas Hisch * Tzu-ping Chung * feuillemorte Happy testing, The Pytest Development Team

1 0

codespeak.net down
by Bruno Oliveira Jan. 21, 2018

Jan. 21, 2018

Hi everyone, >From https://github.com/pytest-dev/pytest-xdist/issues/258, codespeak.net is down. Can anybody with access bring it back up? Alternatively we might consider moving its documentation to ReadTheDocs. Cheers, Bruno.

2 2

[proposal] experiment with adapting gitmate.io for automating issue maintenance/triaging tasks
by Ronny Pfannschmidt Jan. 18, 2018

Jan. 18, 2018

Hi Everyone, a while back the people behind gitmate.io did interview me to expand their perspective with focus on how pytest does things as well as how i do certain things at work, they also provided me with a basic example on what i would have done for pytest: https://gitmate.io/report/https:%2F%2Fgithub.com%2Fpytest-dev%2Fpytest i beleive it would help to free up a lof of volunteer time from issue triaging to start and use such a tool. -- Ronny

5 7

Custom test collection with fixtures
by Sterling Paramore Jan. 15, 2018

Jan. 15, 2018

I'm trying to build a plugin that will do something "special" with test functions that are prefixed with "case_". However, I'm having trouble collecting those and using them with fixtures. in conftest.py I have def pytest_pycollect_makeitem(collector, name, obj): if inspect.isfunction(obj) and (name.startswith('case_'): Function = collector._getcustomclass("Function") return Function(name, parent=collector) and in test_mything.py I have: class TestSomething(): @pytest.fixture def scenario(self): pass def case_1(self, scenario): pass But when I run the test, I get an error "TypeError: case_1() missing 1 required positional argument: 'scenario'" How can I create the item so that it runs with the specific fixtures? Thanks, Sterling

2 1

Parametrizing dependent fixtures
by Edgar Ostrowski Jan. 9, 2018

Jan. 9, 2018

Hello pytest team! Recently I've came across a talk about pytest by Gabe Hollombe https://youtu.be/RcN26hznmk4 One thing that he mentioned really caught my eye. Close to the end of the talk he speaks about parametrizing dependent fixtures by using @pytest.mark.parametrize. Here is link to that moment: https://youtu.be/RcN26hznmk4?t=2397 This looks like a very helpful feature. I tired it out on my own and yes it works: https://gist.github.com/Kanguros/e455901f5b940098d1d18628a27cbdb2 Unfortunately I could not find anything about this in the docs. Or maybe I'm just reading them in the wrong way. Anyway I would like to confirm that this is valid way of using the parametrize marker. Does this have any drawbacks? Is it reliable? Up till now I've only been aware of parametrizing fixtures using @pytest.fixture(params=...) Keep up the great work and thank you. Edgar

5 5

Proposal: use milestones again for features/deprecations/removals
by Bruno Oliveira Jan. 8, 2018

Jan. 8, 2018

Hi, We used milestones in the past to track what would go in each release, including bugs and new features, but we have not been using them anymore and I think the reason is because we never usually kept that promise: if we deemed a release should happen soon we just moved all issues forward or removed the milestone from them altogether. I propose we start using milestones again, but only for two reasons: * **internal** planning of new features: we should use milestones as an internal guide of what *should* go into the next feature release. This is not a promise to users, only for us to manage what we think should go into the next release core developer's time allowing. For example, in my mind we should change the default logging options [1], but this is not really defined anywhere except in my head. I would like to use milestones to track that intent. * **promise** of deprecation and removal of old features: we have been using a manual deprecation roadmap [2], but the question of how to keep issues in sync has been nagging in the back of my head. We should track deprecation and removals in the milestones, but we must be sure to followup with them before a feature release is complete. It is important to follow with our policy of deprecation/two minor issues/removal. The idea is to, before a feature release, we check the the issues assigned to that milestone: * for open features, we can decide to ping the developer if they want some more time to get that into that next feature release, otherwise we move it to the next milestone; * for open deprecation/removal issues, we have to make sure to close them before moving with the release. IMHO, milestones should be created only for feature releases; milestones for minor releases don't make much sense in our current development methodology: we can issue bug-fix releases as quickly as we want/need to, so no feature release should really be blocked by a bug, we can always issue a bug-fix right after a certain bug is dealt with. This is an attempt to help our planning and strengthen our deprecation/removal policy. Thoughts? [1] https://github.com/pytest-dev/pytest/issues/3013 [2] https://docs.pytest.org/en/latest/backwards-compatibility.html

2 1

pytest 3.3.2
by Bruno Oliveira Jan. 4, 2018

Jan. 4, 2018

pytest 3.3.2 has just been released to PyPI. This is a bug-fix release, being a drop-in replacement. To upgrade:: pip install --upgrade pytest The full changelog is available at http://doc.pytest.org/en/latest/changelog.html. Thanks to all who contributed to this release, among them: * Anthony Sottile * Antony Lee * Austin * Bruno Oliveira * Florian Bruhin * Floris Bruynooghe * Henk-Jaap Wagenaar * Jurko Gospodnetić * Ronny Pfannschmidt * Srinivas Reddy Thatiparthy * Thomas Hisch Happy testing, The pytest Development Team

1 0