Improve Terminal Output Formatting in pytest-cov

[tsvikas]

This PR improves the formatting of separator lines in coverage reports and enhances the robustness of terminal width handling.

Why?

• To conform to the visuals from pytest headings.
• To allow clear separation of this plugin output from the previous section

Changes:

• Add a new section heading for the coverage tests output.
• Make all headings the same width as pytest's headings.
• Change separator character of regular headings from - to _.

[webknjaz]

It'd be useful to see some output examples in the PR description, including comparison. Also, such changes usually require prior discussion.

[tsvikas]

Thanks for the feedback!

My apologies for not initiating a discussion. I thought it'll be useful to have the code and output visible when discussing the change.

Here's an example of the updated output (with a terminal width of 100) for clarity. Let me know if you have any concerns!

Before

======================================= test session starts ========================================
platform linux -- Python 3.13.1, pytest-8.3.4, pluggy-1.5.0
benchmark: 5.0.1 (defaults: timer=time.perf_counter disable_gc=False min_rounds=5 min_time=0.000005 max_time=1.0 calibration_precision=10 warmup=False warmup_iterations=100000)
rootdir: /tmp/py-temp
configfile: pyproject.toml
plugins: cov-6.0.0, benchmark-5.0.1, loguru-0.4.0, reverse-1.8.0, clarity-1.0.1
collected 4 items

tests/test_cli.py .F.                                                                        [ 75%]
tests/test_.py .                                                                             [100%]

============================================= FAILURES =============================================
_________________________________________ test_app_version _________________________________________

    def test_app_version() -> None:
        result = runner.invoke(app, ["--version"])
        assert result.exit_code == 0
        assert __version__ in result.stdout
>       assert False
E       assert False

result     = <Result okay>

tests/test_cli.py:22: AssertionError

---------- coverage: platform linux, python 3.13.1-final-0 -----------
Name                    Stmts   Miss  Cover
-------------------------------------------
src/ptemp/__init__.py       3      0   100%
src/ptemp/cli.py           19      0   100%
-------------------------------------------
TOTAL                      22      0   100%

===================================== short test summary info ======================================
FAILED tests/test_cli.py::test_app_version - assert False
=================================== 1 failed, 3 passed in 0.33s ====================================

After:

======================================= test session starts ========================================
platform linux -- Python 3.13.1, pytest-8.3.4, pluggy-1.5.0
benchmark: 5.0.1 (defaults: timer=time.perf_counter disable_gc=False min_rounds=5 min_time=0.000005 max_time=1.0 calibration_precision=10 warmup=False warmup_iterations=100000)
rootdir: /tmp/py-temp
configfile: pyproject.toml
plugins: cov-6.0.0, benchmark-5.0.1, loguru-0.4.0, reverse-1.8.0, clarity-1.0.1
collected 4 items

tests/test_cli.py .F.                                                                        [ 75%]
tests/test_.py .                                                                             [100%]

============================================= FAILURES =============================================
_________________________________________ test_app_version _________________________________________

    def test_app_version() -> None:
        result = runner.invoke(app, ["--version"])
        assert result.exit_code == 0
        assert __version__ in result.stdout
>       assert False
E       assert False

result     = <Result okay>

tests/test_cli.py:22: AssertionError

========================================= coverage report ==========================================
_________________________ coverage: platform linux, python 3.13.1-final-0 __________________________
Name                    Stmts   Miss  Cover
-------------------------------------------
src/ptemp/__init__.py       3      0   100%
src/ptemp/cli.py           19      0   100%
-------------------------------------------
TOTAL                      22      0   100%

===================================== short test summary info ======================================
FAILED tests/test_cli.py::test_app_version - assert False
=================================== 1 failed, 3 passed in 0.18s ====================================

[The-Compiler]

I agree your proposed output looks nicer (and indeed it helps to have a "preview"!), just one nitpick about it: With

========================================= coverage report ==========================================
_________________________ coverage: platform linux, python 3.13.1-final-0 __________________________
Name                    Stmts   Miss  Cover
-------------------------------------------
src/ptemp/__init__.py       3      0   100%
src/ptemp/cli.py           19      0   100%
-------------------------------------------
TOTAL                      22      0   100%

do the two separators really make sense, given that there will only ever be one coverage report (I think?). I'd have expected something like:

========================================= coverage report ==========================================
Name                    Stmts   Miss  Cover
-------------------------------------------
src/ptemp/__init__.py       3      0   100%
src/ptemp/cli.py           19      0   100%
-------------------------------------------
TOTAL                      22      0   100%

platform linux, python 3.13.1-final-0

or maybe just

========================= coverage: platform linux, python 3.13.1-final-0 ==========================
Name                    Stmts   Miss  Cover
-------------------------------------------
src/ptemp/__init__.py       3      0   100%
src/ptemp/cli.py           19      0   100%
-------------------------------------------
TOTAL                      22      0   100%

[tsvikas]

As per suggestion, I moved the heading to pytest_terminal_summary. It seems to fit there better :).

It also helped me notice two small behaviors that I changed (I can revert them if needed):

• Renamed the heading from "coverage report" to "tests coverage" (since in some cases, it's not a full report but a warning).
• Adjusted newlines to match pytest's style (one newline after _ headings, no newlines before/after = headings).

[tsvikas]

current output (120 columns):

================================================= test session starts ==================================================
platform linux -- Python 3.13.1, pytest-8.3.4, pluggy-1.5.0
benchmark: 5.0.1 (defaults: timer=time.perf_counter disable_gc=False min_rounds=5 min_time=0.000005 max_time=1.0 calibration_precision=10 warmup=False warmup_iterations=100000)
rootdir: /tmp/py-temp
configfile: pyproject.toml
plugins: cov-6.0.0, benchmark-5.0.1, loguru-0.4.0, reverse-1.8.0, clarity-1.0.1
collected 5 items

tests/test_.py .                                                                                                 [ 20%]
tests/test_cli.py .FF.                                                                                           [100%]

======================================================= FAILURES =======================================================
___________________________________________________ test_app_version ___________________________________________________

    def test_app_version() -> None:
        result = runner.invoke(app, ["--version"])
        assert result.exit_code == 0
        assert __version__ in result.stdout
>       assert False
E       assert False

result     = <Result okay>

tests/test_cli.py:22: AssertionError
__________________________________________________ test_app_version2 ___________________________________________________

    def test_app_version2() -> None:
        result = runner.invoke(app, ["--version"])
        assert result.exit_code == 0
        assert __version__ in result.stdout
>       assert False
E       assert False

result     = <Result okay>

tests/test_cli.py:28: AssertionError
==================================================== tests coverage ====================================================
___________________________________ coverage: platform linux, python 3.13.1-final-0 ____________________________________

Name                    Stmts   Miss  Cover
-------------------------------------------
src/ptemp/__init__.py       3      0   100%
src/ptemp/cli.py           19      0   100%
-------------------------------------------
TOTAL                      22      0   100%
=============================================== short test summary info ================================================
FAILED tests/test_cli.py::test_app_version - assert False
FAILED tests/test_cli.py::test_app_version2 - assert False
============================================= 2 failed, 3 passed in 0.18s ==============================================

[tsvikas]

I agree your proposed output looks nicer (and indeed it helps to have a "preview"!), just one nitpick about it: With

Thank you :)

========================================= coverage report ==========================================
_________________________ coverage: platform linux, python 3.13.1-final-0 __________________________
Name                    Stmts   Miss  Cover
-------------------------------------------
src/ptemp/__init__.py       3      0   100%
src/ptemp/cli.py           19      0   100%
-------------------------------------------
TOTAL                      22      0   100%

do the two separators really make sense, given that there will only ever be one coverage report (I think?). I'd have expected something like:

========================================= coverage report ==========================================
Name                    Stmts   Miss  Cover
-------------------------------------------
src/ptemp/__init__.py       3      0   100%
src/ptemp/cli.py           19      0   100%
-------------------------------------------
TOTAL                      22      0   100%

platform linux, python 3.13.1-final-0

or maybe just

========================= coverage: platform linux, python 3.13.1-final-0 ==========================
Name                    Stmts   Miss  Cover
-------------------------------------------
src/ptemp/__init__.py       3      0   100%
src/ptemp/cli.py           19      0   100%
-------------------------------------------
TOTAL                      22      0   100%

I saw in engine.py that self.sep, the function responsible for creating _ headings, is called in several different variations (many workers / one worker), and, in the event of a failed worker, it generate two _ headings.

So, I assumed that using a constant = heading for the whole section would be beneficial.

Modifying or rearranging the _ lines or the rest of the output content might also be beneficial, but I assumed that it is beyond the scope of this PR, and would require input from the package owners.

[tsvikas]

refactored

[tsvikas]

Hey @The-Compiler , just checking in—do you have any further feedback on this? I’ve incorporated the suggested changes and would love to get this moving forward. Let me know if anything else needs adjusting!

Also, I see there's a workflow approval pending—could someone with merge access take a look?

[The-Compiler]

Two more small considerations. Other than that, this looks good to me, but I'll leave merging to someone who's more involved with pytest-cov than I am.

[tsvikas]

Thanks, @The-Compiler! I've addressed all the changes. I noticed the @maintainers link isn't working. Is there a way to ping someone for merging?

[The-Compiler]

As a general rule, please don't ping maintainers in their own projects unless it's something absolutely critical. You can expect maintainers to be subscribed to all activity in their own projects, and/or to be periodically checking things on their own schedule.

Remember that projects are often maintained by a single person in their spare time, often with various other projects on their hands as well. You won't be the only person pinging them in a typical week, or sometimes even day. It usually make things far more stressful than they would be otherwise. Sometimes people are busy with other stuff, or on holidays, or have a tight work deadline, and then open source things will have to wait for a bit.

[tsvikas]

Thank you. most of my coding was outside GitHub, so I am new to the GitHub system and etiquette, and happy to learn.
Did you reference the at-maintainers ping, or also the at-The-Compiler ping?

[The-Compiler]

That was fine IMHO, for two reasons:

• I'm not a primary maintainer of pytest-cov, so I don't look at it regularly (and might indeed have missed this in my notifications)
• More importantly, you interacted with me about this thing previously, so it's about something specific that indeed needs attention from me in particular.

[tsvikas]

Hey, just a quick check-in—I've addressed all requested changes, and the failing tests seem unrelated to this PR. Let me know if anything else is needed before merging. Thanks!

[webknjaz]

While the failing tests may be unrelated, they may still block the PR from being merged. Sometimes, the fastest way of solving speeding up the process is making another PR fixing those problems and then rebasing.

Most projects won't be force-merging PRs with red CI and would wish to keep the main branch green before anything is allowed in.

The link check likely fails because GH changed the way they inject anchors into web pages. Sphinx has a toggle to skip this for certain websites. That would be the solution. But I'd also check that the linked thing still exists.

[tsvikas]

@webknjaz I've opened PR #680 to address the link check failures we discussed. It's ready for review, but requires a maintainer's approval to run the workflow. Could you or someone else please take a look when you have a chance? Thank you!

[webknjaz]

You just have to wait patiently now and hope the primary maintainers get to it eventually.

[ionelmc]

This seems fine, thank you. I'll try to release this week.