Thanks everyone for your feedback! I have created a PR: https://github.com/pytest-dev/pytest/pull/6316 Let us continue the discussion there, please let me know what I can do to get this in.
Cheers, Christoph Am Do., 5. Dez. 2019 um 00:40 Uhr schrieb Brian Okken < variedthoug...@gmail.com>: > Oops. My bad. > I'm used to running with -ra or -rf, which will produce the summary with > the test names. > - Brian > > On Wed, Dec 4, 2019 at 3:37 PM Brian Okken <variedthoug...@gmail.com> > wrote: > >> Oscar, >> > " It would be nice if that string were included in the output from test >> failures. " >> I'm pretty sure it is. >> ... >> =========================== short test summary info >> =========================== >> FAILED test_foo.py::test_one_more >> ===================== 1 failed, 1 passed in 0.16 seconds >> ====================== >> ... >> - Brian >> >> >> >> On Wed, Dec 4, 2019 at 3:21 PM Oscar Benjamin <oscar.j.benja...@gmail.com> >> wrote: >> >>> Ah thanks. I guess you mean >>> >>> $ pytest somefile.py::test_xxx >>> >>> which does indeed work. It would be nice if that string were included >>> in the output from test failures. >>> >>> -- >>> Oscar >>> >>> On Wed, 4 Dec 2019 at 23:12, Floris Bruynooghe <f...@devork.be> wrote: >>> > >>> > Using the full test id as shown by -v is what I always use for this >>> case instead of using -k >>> > >>> > On Wed, 4 Dec 2019, 23:58 Bruno Oliveira, <nicodde...@gmail.com> >>> wrote: >>> >> >>> >> Hi Oscar, >>> >> >>> >> Not right now, the matching is always partial... not sure how we >>> could signal to `-k` that we want an exact match of the last part of the >>> node id (which seems what you want). >>> >> >>> >> Cheers, >>> >> >>> >> On Wed, Dec 4, 2019 at 7:40 PM Oscar Benjamin < >>> oscar.j.benja...@gmail.com> wrote: >>> >>> >>> >>> As an aside, I would often like to use -k and have an exact match so >>> e.g. I do >>> >>> >>> >>> $ pytest -k test_xxx >>> >>> >>> >>> and I want that to run test_xxx only and not test_xxx_1 etc. Is there >>> >>> a way to do that? >>> >>> >>> >>> -- >>> >>> Oscar >>> >>> >>> >>> On Wed, 4 Dec 2019 at 20:56, Bruno Oliveira <nicodde...@gmail.com> >>> wrote: >>> >>> > >>> >>> > Thanks everyone for their input! >>> >>> > >>> >>> > Christoph feel free to open a PR targeting the `features` branch >>> with this change. >>> >>> > >>> >>> > For now I don't think we need an option to revert to the old >>> behavior; if people claim for it we can consider adding it in the future >>> though. >>> >>> > >>> >>> > Cheers, >>> >>> > Bruno >>> >>> > >>> >>> > On Wed, Dec 4, 2019 at 12:38 PM RonnyPfannschmidt < >>> opensou...@ronnypfannschmidt.de> wrote: >>> >>> >> >>> >>> >> Hi all, >>> >>> >> >>> >>> >> it seems to me that a change to >>> >>> >> >>> >>> >> >>> https://github.com/pytest-dev/pytest/blob/master/src/_pytest/mark/legacy.py#L28 >>> >>> >> >>> >>> >> >>> >>> >> in addition to ensuring lowercase of the expression is all that's >>> needed >>> >>> >> on the technical side >>> >>> >> >>> >>> >> on the release management side its a breaking change that needs a >>> major >>> >>> >> release >>> >>> >> >>> >>> >> nonetheless i'm all for it. >>> >>> >> >>> >>> >> i wonder about the case sensitivity of mark expressions as well >>> >>> >> >>> >>> >> >>> >>> >> -- Ronny >>> >>> >> >>> >>> >> >>> >>> >> Am 04.12.19 um 15:55 schrieb Brian Okken: >>> >>> >> > I think switching to case insensitive by default would be fine. >>> Do we need a flag for case sensitive? Not sure. >>> >>> >> > >>> >>> >> > - Brian >>> >>> >> > >>> >>> >> >> On Dec 4, 2019, at 6:26 AM, Florian Bruhin < >>> m...@the-compiler.org> wrote: >>> >>> >> >> >>> >>> >> >> Hey, >>> >>> >> >> >>> >>> >> >>> On Wed, Dec 04, 2019 at 10:58:09AM -0300, Bruno Oliveira >>> wrote: >>> >>> >> >>> I would actually vote to change the existing behavior to be >>> >>> >> >>> case-insensitive. I doubt it would break many suites, if at >>> all, and would >>> >>> >> >>> be more in alignment with the intent of the option, more of >>> it being a >>> >>> >> >>> "partial match" than an exact match, as it matches against >>> any portion of >>> >>> >> >>> the node id currently anyway. >>> >>> >> >> Sounds entirely reasonable to me! >>> >>> >> >> >>> >>> >> >> Florian >>> >>> >> >> >>> >>> >> >> -- >>> >>> >> >> m...@the-compiler.org (Mail/XMPP) | https://www.qutebrowser.org >>> >>> >> >> https://bruhin.software/ | >>> https://github.com/sponsors/The-Compiler/ >>> >>> >> >> 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@python.org >>> >>> >> >> https://mail.python.org/mailman/listinfo/pytest-dev >>> >>> >> > _______________________________________________ >>> >>> >> > pytest-dev mailing list >>> >>> >> > pytest-dev@python.org >>> >>> >> > https://mail.python.org/mailman/listinfo/pytest-dev >>> >>> >> _______________________________________________ >>> >>> >> pytest-dev mailing list >>> >>> >> pytest-dev@python.org >>> >>> >> https://mail.python.org/mailman/listinfo/pytest-dev >>> >>> > >>> >>> > _______________________________________________ >>> >>> > pytest-dev mailing list >>> >>> > pytest-dev@python.org >>> >>> > https://mail.python.org/mailman/listinfo/pytest-dev >>> >> >>> >> _______________________________________________ >>> >> pytest-dev mailing list >>> >> pytest-dev@python.org >>> >> https://mail.python.org/mailman/listinfo/pytest-dev >>> _______________________________________________ >>> pytest-dev mailing list >>> pytest-dev@python.org >>> https://mail.python.org/mailman/listinfo/pytest-dev >>> >> _______________________________________________ > pytest-dev mailing list > pytest-dev@python.org > https://mail.python.org/mailman/listinfo/pytest-dev >
_______________________________________________ pytest-dev mailing list pytest-dev@python.org https://mail.python.org/mailman/listinfo/pytest-dev
