Keep consistency in the output

[azmeuk]

Right now, when a test fails the output looks like this:

...
Results (2.34s):
       5 passed
       1 failed
         - path/to/your_test.py:666 test_something_wrong

The way the failing test (ie PATH:LINE TEST) is displayed is not the natural way pytest displays test paths (ie PATH::TEST), and I think it is unpractical for some reasons:

• I frequently need to copy/paste this line to pass it as an argument of a new pytest invocation in your shell, for example, with new debugging options. Then I have to clean the line numbers, and add a colon, and delete a space. Once, it is not a big deal, but it is a bit annoying when you do this dozen times a day.
• Using thing like kitty hints, the space in the report makes kitty only catch the filename, and not the whole test path, making the hint feature useless in that situation.

A more practical way to display the report would be to keep the test path the way pytest use them. For example what do you think of this output?

...
Results (2.34s):
       5 passed
       1 failed
         - path/to/your_test.py::test_something_wrong :666

If you agree, I am willing to make a pull request. What do you think?

Cheers

[blueyed]

Just for reference: pytest should also be able to run tests via file:lineno (WIP at pytest-dev/pytest#3282).

• Using thing like kitty hints, the space in the report makes kitty only catch the filename, and not the whole test path, making the hint feature useless in that situation.

Do you mean a custom hint, which fails because it cannot include the space?

• path/to/your_test.py::test_something_wrong :666

I'd prefer - path/to/your_test.py::test_something_wrong, line 666. This appears to be more common.

Would path/to/your_test.py::test_something_wrong:666 also work / make sense?

Anyway, in general this repo appears to be quite inactive currently, and CI would fail for your PR anyway, but feel free to give it a try already!

This is something that annoyed me also about pytest-sugar (I am not using it currently), and thought I had done some PR in this regard myself, but could not find it.

Check out #172 also.

[blueyed]

There is some discussion / brainstorming with regard to this in pytest itself: pytest-dev/pytest#5002 (comment).

[Teemu]

In my use cases I usually just want to jump into the file rather than running it again with pytest so the line number next to the filename is really handy (at least iTerm2 allows direct jump with the line number)

[blueyed]

Related: pytest-dev/pytest#5241
Unfortunately this got no traction in pytest itself, but I have it in my (more serious) fork (https://github.com/blueyed/pytest/), where it has the line numbers in the short test summary then also. This is very useful.
btw: https://github.com/wsdjeg/vim-fetch handles the nodeids also, but only goes to the function itself then.

[nicoddemus]

OK, thanks for the clarification.