Mailman 3 June 2019 - pytest-dev

enhancing the assertion rewriting experience with custom integration/workflows
by Ronny Pfannschmidt July 29, 2019

July 29, 2019

Hi everyone, at a project at work which integrates pytest we did build a custom workflow around invoking tests and pytest. This in turn triggers a lot of warnings from the assertion rewriter about things that have been already imported. at first glance fixing this seems rather problematic, as the configuration of the assertion rewriting is deeply bound to the pytest configuration and it seems we cant do something simple and crude like letting a pth file fix the issue. i believe opening up the hooking system could be best done by moving it to a package with some sort of singleton control anyway - then pytest would be just a consumer of that api enabling if not enabled and push in its own "import roots". i'd like ot hear other impressions and ideas on this as well. -- Ronny

2 2

Indeed.com FOSS Contributor Fund and OpenCollective
by Bruno Oliveira June 29, 2019

June 29, 2019

Hi everyone! Recently pytest has been elected to receive a donation from Indeed.com, in their FOSS contributor fund initiative. On it, each month open source contributors who work at Indeed get the opportunity to vote for a project which will receive a monetary donation. Contributors for May have elected pytest to receive the donation for that month! Congratulations everyone! I'm sure we are all happy and grateful to Indeed.com for their generous donation. We (me and a few other maintainers) have been talking with Duane, head of the Open Source at Indeed.com about how pytest could receive the donation. We have reached the conclusion that the best way for them to donate the money would be to a platform which accepts one-time, direct donations, for which we have chosen OpenCollective. OpenCollective is a good fit in this case because Indeed wants to make a one-time donation directly to the pytest project. Tidelift has been considered for that, given that we are already members and are happy with it in general, but with conversations with Keenan (Developer Engagement at Tidelift) it became clear that the Tidelift model, which is long-time subscriptions targeted to companies, was not a good fit for this case. Besides this recent donation, over the years many times people have approached pytest team members wanting to make a small donation for the project, but we never really had a venue for them to do so, and OpenCollective seems to fit the bill nicely for this case: one-time or recurring donations directly to the project, from companies or individuals. I've setup an Open Collective account for pytest at: https://opencollective.com/pytest I would like to add all core maintainers to the collective (active or not), and have already added a few, but I'm afraid I don't have all the emails from the list of core maintainers: https://github.com/orgs/pytest-dev/teams/core/members So if you are a core maintainer and don't receive an email with an invitation in the next couple of days, please message me in private so I can add you. The purpose of the collective, so far, is to fund future gatherings (for example, Florians has some plans in the background about another Sprint sometime next year) and overall maintenance. Nothing more concrete than that, but we should be nailing down the details in the next few days. I plan to also add a document to the repository (similar to what was done with Tidelift) clearly describing the objectives and guidelines of the collective. Cheers!

1 1

pytest 4.6.4 released!
by Anthony Sottile June 29, 2019

June 29, 2019

pytest 4.6.4 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 https://docs.pytest.org/en/latest/changelog.html. Thanks to all who contributed to this release, among them: * Anthony Sottile * Bruno Oliveira * Daniel Hahler * Thomas Grainger * Zac Hatfield-Dodds Happy testing, The pytest Development Team

1 0

pytest 5.0.0 released!
by Anthony Sottile June 29, 2019

June 29, 2019

The pytest team is proud to announce the 5.0.0 release! pytest is a mature Python testing tool with more than a 2000 tests against itself, passing on many different interpreters and platforms. This release contains a number of bugs fixes and improvements, so users are encouraged to take a look at the CHANGELOG: https://docs.pytest.org/en/latest/changelog.html **As a special note**: The 5.X series is the first series to drop support for Python 2 and Python 3.4. For more details, see our Python 2.7 and 3.4 support plan: https://docs.pytest.org/en/latest/py27-py34-deprecation.html For complete documentation, please visit: https://docs.pytest.org/en/latest/ As usual, you can upgrade from pypi via: pip install -U pytest Thanks to all who contributed to this release, among them: * Anthony Sottile * Bruno Oliveira * Daniel Hahler * Dirk Thomas * Evan Kepner * Florian Bruhin * Hugo * Kevin J. Foley * Pulkit Goyal * Ralph Giles * Ronny Pfannschmidt * Thomas Grainger * Thomas Hisch * Tim Gates * Victor Maryama * Yuri Apollov * Zac Hatfield-Dodds * curiousjazz77 * patriksevallius Happy testing, The Pytest Development Team

1 0

Re: [pytest-dev] Customising repr() output for super-expressions of failed assertions
by Nicholas Williams June 13, 2019

June 13, 2019

We had a different approach altogether. We do something like this, which prints both the diff and the content, but doesn’t print the content if there’s no failure: assert response.status == 200, response.content.decode('utf-8') Now the response content is used as the assertion error message, so if the status code isn’t 200, the incorrect status code AND the content are printed. Nick On Thu, Jun 13, 2019 at 7:09 AM Nicholas Williams < nicholas(a)nicholaswilliams.net> wrote: > We had a different approach altogether. We do something like this, which > prints both the diff and the content, but doesn’t print the content if > there’s no failure: > > assert response.status == 200, response.content.decode('utf-8') > > Now the response content is used as the assertion error message, so if the > status code isn’t 200, the incorrect status code AND the content are > printed. > > Nick > > Sent from my iPhone, so please forgive brief replies and frequent typos > > On Jun 13, 2019, at 05:28, Joep Schuurkes <j19sch(a)gmail.com> wrote: > > Not sure if this would work for your setup, but we solved that by defining > a generic api client class with a logging method that's added to the hooks > on the response object of the requests library. Each specific api client > class then inherits from the generic one. > > Regards, > Joep > > On Thu, Jun 13, 2019, 12:19 Craig de Stigter <craig.ds(a)gmail.com> wrote: > >> Thanks for the replies. >> >> We do already use the print-before-assert pattern. It'd be nice to be >> able to fold this away in a hook so each individual request test doesn't >> need to think about it. But using print() is perfectly fine too :) >> >> >> >> >> On Thu, 13 Jun 2019 at 19:35, Joep Schuurkes <j19sch(a)gmail.com> wrote: >> >>> Hi, >>> >>> On Thu, Jun 13, 2019, 10:25 Florian Bruhin <me(a)the-compiler.org> wrote: >>> >>>> Hey, >>>> >>>> On Thu, Jun 13, 2019 at 12:02:01PM +1200, Craig de Stigter wrote: >>>> > This output isn't terribly useful at present. We'd like to >>>> automatically >>>> > dump the request body (`r.content`) in the output, wherever it's a >>>> django >>>> > response object, to aid debugging. >>>> >>>> It'd be cool if this were possible with hooks (I'm not sure whether it >>>> is) - >>>> but FWIW, what I've done so far in such situations is >>>> "print(r.content)" in the >>>> test. That way, pytest shows you the output when a test failed, but >>>> hides it >>>> for passing tests. >>>> >>>> Florian >>>> >>>> -- >>>> https://www.qutebrowser.org | me(a)the-compiler.org (Mail/XMPP) >>>> GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc >>>> I love long mails! | https://email.is-not-s.ms/ >>>> _______________________________________________ >>>> pytest-dev mailing list >>>> pytest-dev(a)python.org >>>> https://mail.python.org/mailman/listinfo/pytest-dev >>> >>> >>> We use logging similar to the print mentioned by Florian. I also created >>> a pytest plugin to have some options for how the generated logs are written >>> to file: https://pypi.org/project/pytest-logfest/ >>> >>> Regards, >>> Joep >>> >> _______________________________________________ > pytest-dev mailing list > pytest-dev(a)python.org > https://mail.python.org/mailman/listinfo/pytest-dev > >

1 0

Customising repr() output for super-expressions of failed assertions
by Craig de Stigter June 13, 2019

June 13, 2019

Hi there Considering this failed assertion where a django test request failed: ``` > assert r.status_code == 201 E assert 400 == 201 E -400 E +201 ``` This output isn't terribly useful at present. We'd like to automatically dump the request body (`r.content`) in the output, wherever it's a django response object, to aid debugging. I see the `pytest_assertrepr_compare` hook gets passed the top-level objects and the operator for writing a custom message. However if I'm reading it right there's no way to access the containing expression there (i.e. `r`) and treat it specially. Is there a way to do this using pytest's hooks? Cheers Craig de Stigter

3 4

class-based markers API discussion
by Bruno Oliveira June 12, 2019

June 12, 2019

Hi everyone, We have started a discussion over Ronny's proposal of using class-based markers at https://github.com/pytest-dev/pytest/issues/5424, everyone is welcome to join. (Sending an email here as many people don't follow GitHub discussions closely and will probably miss that). Cheers, Bruno.

1 0

pytest 4.6.3 released
by Anthony Sottile June 11, 2019

June 11, 2019

pytest 4.6.3 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 https://docs.pytest.org/en/latest/changelog.html. Thanks to all who contributed to this release, among them: * Anthony Sottile * Bruno Oliveira * Daniel Hahler * Dirk Thomas Happy testing, The pytest Development Team

1 0

pytest 4.6.2 released
by Anthony Sottile June 3, 2019

June 3, 2019

pytest 4.6.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 https://docs.pytest.org/en/latest/changelog.html. Thanks to all who contributed to this release, among them: * Anthony Sottile Happy testing, The pytest Development Team

1 0

pytest 4.6.1 released
by Anthony Sottile June 2, 2019

June 2, 2019

pytest 4.6.1 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 https://docs.pytest.org/en/latest/changelog.html. Thanks to all who contributed to this release, among them: * Anthony Sottile * Bruno Oliveira Happy testing, The pytest Development Team

1 0