Test selection syntax is baroque and foreign

[nedbat]

When I want to run a single test, I have to use an odd double-colon syntax:

$ pytest tests/test_api.py::ReportIncludeOmitTest::test_include

Double-colons appear nowhere in Python. If the test fails, pytest even reports the failure to me using the usual single-dot syntax:

=================================== FAILURES ===================================
______________________ ReportIncludeOmitTest.test_include ______________________

Please allow the more usual single-dot syntax, and perhaps a single colon between file and class?

$ pytest tests/test_api.py:ReportIncludeOmitTest.test_include

Versions:

$ pytest --version
This is pytest version 3.0.5, imported from /usr/local/virtualenvs/coverage/lib/python2.7/site-packages/pytest.pyc
setuptools registered plugins:
  pytest-xdist-1.15.0 at /usr/local/virtualenvs/coverage/lib/python2.7/site-packages/xdist/boxed.py
  pytest-xdist-1.15.0 at /usr/local/virtualenvs/coverage/lib/python2.7/site-packages/xdist/looponfail.py
  pytest-xdist-1.15.0 at /usr/local/virtualenvs/coverage/lib/python2.7/site-packages/xdist/plugin.py
  pytest-warnings-0.2.0 at /usr/local/virtualenvs/coverage/lib/python2.7/site-packages/pytest_warnings/__init__.pyc

[nicoddemus]

Hi @nedbat, thanks for writing.

I agree the current style is a little odd, but for backward compatibility reasons it is here to stay.

Your suggestion:

$ pytest tests/test_api.py:ReportIncludeOmitTest.test_include

As an addition to the current style is probably doable, I think.

[nedbat]

If we wanted to be truly convenient, then accept a variety of punctuation, etc, and figure it out.

tests/test_api.py:ReportIncludeOmitTest.test_include
tests/test_api.py.ReportIncludeOmitTest.test_include
tests/test_api:ReportIncludeOmitTest.test_include
tests.test_api:ReportIncludeOmitTest.test_include
tests.test_api.ReportIncludeOmitTest.test_include

etc. What's the harm in finding the thing the user must have meant?

[RonnyPfannschmidt]

@nedbat the main harm in pretending to understand the user is getting it wrong - which is easy

for example argparse does it in python by default, and it creates bad bugs in py.test for early parsing of cli args where a plugin registers an option that matches the prefix of a core option while having different semantics

if it was an opt-in like --pyargs it would be more easy to work with it/reason about it

[nedbat]

@RonnyPfannschmidt OK, I knew the "dwim" feature idea might be unpopular. Are you ok with the "foo.py:class.method" syntax?

[RonnyPfannschmidt]

@nedbat i like that syntax, it may even be a good idea to eventually switch over to it

we just have to consider time-frames, and we should figure a consistent way to express parameters with it

[nicoddemus]

we should figure a consistent way to express parameters with it

Do you foresee any problems with it @RonnyPfannschmidt? I didn't look too much into it, but I think the first step would be to find all places where there's some handling of the current syntax ("::") and replace those by thin wrappers. After that, it would be a matter of adding support for the new syntax in those thin wrappers. Of course that's a simplistic version and there might be other problems that I'm not foreseeing.

[RonnyPfannschmidt]

@nicoddemus i'm under the impression this one will be one of those hindsight things as well ^^