pytest-sugar
pytest-sugar copied to clipboard
Teemu
Keep consistency in the output
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
Just for reference: pytest should also be able to run tests via file:lineno (WIP at https://github.com/pytest-dev/pytest/pull/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 https://github.com/Frozenball/pytest-sugar/pull/172 also.
There is some discussion / brainstorming with regard to this in pytest itself: https://github.com/pytest-dev/pytest/pull/5002#issuecomment-477233062.
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)
Related: https://github.com/pytest-dev/pytest/issues/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 See https://github.com/blueyed/pytest/#pytest-with-enhancements.
As for line numbers (which would be on-topic here), it was you that told me multiple times that nothing can be done there until some refactoring (for years IIRC), so I've started to hack on getting it for myself at least. This has gone through multiple iterations already (pending https://github.com/blueyed/pytest/pull/260 currently), and might finally land in pytest one day, but until then it is only in my fork.
Actually my question was about your "more serious" remark, meaning that the project and maintainers don't take things seriously, which I have issue with. But OK.
@nicoddemus I've meant "more serious" than a typical fork-for-PRs. It was comparing it to forks in general, not pytest itself.