From asottile+pytest at umich.edu Sat Jun 1 14:11:52 2019 From: asottile+pytest at umich.edu (Anthony Sottile) Date: Sat, 1 Jun 2019 11:11:52 -0700 Subject: [pytest-dev] pytest 4.6.0 released! Message-ID: The pytest team is proud to announce the 4.6.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 4.6.X series will be the last series to support 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: * Akiomi Kamakura * Anthony Sottile * Bruno Oliveira * Daniel Hahler * David R?thlisberger * Evan Kepner * Jeffrey Rackauckas * MyComputer * Nikita Krokosh * Raul Tambre * Thomas Hisch * Tim Hoffmann * Tomer Keren * Victor Maryama * danielx123 * oleg-yegorov Happy testing, The Pytest Development Team From asottile+pytest at umich.edu Sun Jun 2 14:51:30 2019 From: asottile+pytest at umich.edu (Anthony Sottile) Date: Sun, 2 Jun 2019 11:51:30 -0700 Subject: [pytest-dev] pytest 4.6.1 released Message-ID: 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 From asottile+pytest at umich.edu Mon Jun 3 15:21:31 2019 From: asottile+pytest at umich.edu (Anthony Sottile) Date: Mon, 3 Jun 2019 12:21:31 -0700 Subject: [pytest-dev] pytest 4.6.2 released Message-ID: 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 From asottile+pytest at umich.edu Tue Jun 11 13:00:34 2019 From: asottile+pytest at umich.edu (Anthony Sottile) Date: Tue, 11 Jun 2019 10:00:34 -0700 Subject: [pytest-dev] pytest 4.6.3 released Message-ID: 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 From nicoddemus at gmail.com Wed Jun 12 09:29:33 2019 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Wed, 12 Jun 2019 10:29:33 -0300 Subject: [pytest-dev] class-based markers API discussion Message-ID: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.ds at gmail.com Wed Jun 12 20:02:01 2019 From: craig.ds at gmail.com (Craig de Stigter) Date: Thu, 13 Jun 2019 12:02:01 +1200 Subject: [pytest-dev] Customising repr() output for super-expressions of failed assertions Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at the-compiler.org Thu Jun 13 03:18:41 2019 From: me at the-compiler.org (Florian Bruhin) Date: Thu, 13 Jun 2019 09:18:41 +0200 Subject: [pytest-dev] Customising repr() output for super-expressions of failed assertions In-Reply-To: References: Message-ID: <20190613071819.odh3kygyhiwfn7us@hooch.localdomain> 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 at 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From j19sch at gmail.com Thu Jun 13 03:35:24 2019 From: j19sch at gmail.com (Joep Schuurkes) Date: Thu, 13 Jun 2019 10:35:24 +0300 Subject: [pytest-dev] Customising repr() output for super-expressions of failed assertions In-Reply-To: <20190613071819.odh3kygyhiwfn7us@hooch.localdomain> References: <20190613071819.odh3kygyhiwfn7us@hooch.localdomain> Message-ID: Hi, On Thu, Jun 13, 2019, 10:25 Florian Bruhin 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 at 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 at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.ds at gmail.com Thu Jun 13 05:19:43 2019 From: craig.ds at gmail.com (Craig de Stigter) Date: Thu, 13 Jun 2019 21:19:43 +1200 Subject: [pytest-dev] Customising repr() output for super-expressions of failed assertions In-Reply-To: References: <20190613071819.odh3kygyhiwfn7us@hooch.localdomain> Message-ID: 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 wrote: > Hi, > > On Thu, Jun 13, 2019, 10:25 Florian Bruhin 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 at 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 at 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From j19sch at gmail.com Thu Jun 13 06:28:33 2019 From: j19sch at gmail.com (Joep Schuurkes) Date: Thu, 13 Jun 2019 13:28:33 +0300 Subject: [pytest-dev] Customising repr() output for super-expressions of failed assertions In-Reply-To: References: <20190613071819.odh3kygyhiwfn7us@hooch.localdomain> Message-ID: 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 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 wrote: > >> Hi, >> >> On Thu, Jun 13, 2019, 10:25 Florian Bruhin 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 at 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 at 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 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicholas+pytest at nicholaswilliams.net Thu Jun 13 11:38:04 2019 From: nicholas+pytest at nicholaswilliams.net (Nicholas Williams) Date: Thu, 13 Jun 2019 10:38:04 -0500 Subject: [pytest-dev] Customising repr() output for super-expressions of failed assertions In-Reply-To: <955B5653-DB6D-44CB-BE3D-E242B567CE2C@nicholaswilliams.net> References: <20190613071819.odh3kygyhiwfn7us@hooch.localdomain> <955B5653-DB6D-44CB-BE3D-E242B567CE2C@nicholaswilliams.net> Message-ID: 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 at 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 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 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 wrote: >> >>> Hi, >>> >>> On Thu, Jun 13, 2019, 10:25 Florian Bruhin 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 at 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 at 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 at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicoddemus at gmail.com Thu Jun 27 17:55:10 2019 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Thu, 27 Jun 2019 18:55:10 -0300 Subject: [pytest-dev] Indeed.com FOSS Contributor Fund and OpenCollective Message-ID: 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! -------------- next part -------------- An HTML attachment was scrubbed... URL: From asottile+pytest at umich.edu Fri Jun 28 21:16:12 2019 From: asottile+pytest at umich.edu (Anthony Sottile) Date: Fri, 28 Jun 2019 18:16:12 -0700 Subject: [pytest-dev] pytest 5.0.0 released! Message-ID: 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 From asottile+pytest at umich.edu Fri Jun 28 22:21:51 2019 From: asottile+pytest at umich.edu (Anthony Sottile) Date: Fri, 28 Jun 2019 19:21:51 -0700 Subject: [pytest-dev] pytest 4.6.4 released! Message-ID: 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 From nicoddemus at gmail.com Sat Jun 29 15:23:40 2019 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Sat, 29 Jun 2019 16:23:40 -0300 Subject: [pytest-dev] Indeed.com FOSS Contributor Fund and OpenCollective In-Reply-To: References: Message-ID: Hey everyone, I've open a PR adding information about OpenCollective and Tidelift to the docs: https://github.com/pytest-dev/pytest/pull/5527 I've added a few maintainers as reviewers, but everybody is encouraged to comment. Cheers, Bruno On Thu, Jun 27, 2019 at 6:55 PM Bruno Oliveira wrote: > 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! > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: