Test listed twice when there's an error during teardown

[The-Compiler]

With this code:

import pytest

@pytest.yield_fixture
def fixt():
    yield
    raise Exception

def test_foo(fixt):
    pass

We get this output:

collected 1 items 

py/test_foo.py::test_foo PASSED
py/test_foo.py::test_foo ERROR

================================== ERRORS ===================================
_______________________ ERROR at teardown of test_foo _______________________

    @pytest.yield_fixture
    def fixt():
        yield
>       raise Exception
E       Exception

py/test_foo.py:6: Exception
===================== 1 passed, 1 error in 0.41 seconds ====================

The test obviously only should be listed once, and no passed tests should be listed.

[hpk42]

it's actually intentional -- each phase out of setup/call/teardown gets its own report (so each test item has three reports) but passed setup/teardown reports are surpressed usually.

[RonnyPfannschmidt]

the ux is confusing that way, can we have one printed report per item
so bascially print the call report when teardown passes, not when call passes?

[moorecm]

As a user, I think some improvements could be made in this area. I can understand instances where users may want to vary how this happens--and I don't think that this means they should have to implement a bunch of hooks to get what they want.

Currently, it seems inconsistent. You don't get PASSED for the setup step that worked, you always get the call step result, and you only get errors from teardown. (By the way, I love how failures and errors are differentiated personally.)

Perhaps not exactly the same issue but I've also noticed how you can print things from setup but finalizers seem to execute outside of the scope that captures output. If print works in setup, it should work in teardown.

[The-Compiler]

What's also a consequence of this - and is pretty annoying with long outputs - is that they're printed twice if there's an issue both during call and teardown:

import pytest

@pytest.yield_fixture
def fixt():
    yield
    raise Exception

def test_foo(fixt):
    print("Hello World")
    raise ValueError

=========================== ERRORS ===========================
_______________ ERROR at teardown of test_foo ________________
pytest-test.py:7: in fixt
    raise Exception
E   Exception
-------------------- Captured stdout call --------------------
Hello World
========================== FAILURES ==========================
__________________________ test_foo __________________________
pytest-test.py:12: in test_foo
    raise ValueError
E   ValueError
-------------------- Captured stdout call --------------------
Hello World

Should I open a separate issue for that?

[mevinbabuc]

Is this getting fixed ?

[nicoddemus]

I don't think this will get fixed actually as it happens by design.

[jeffwright13]

If it's not getting fixed, shouldn't it be closed? As it is now, it's tagged with the 'help wanted' tag, which is why I even looked.

[RonnyPfannschmidt]

it should get fixed, we should print the test passed not after the call, but after the teardown to avoid the double print

[RonnyPfannschmidt]

Re-scoping this after #14896, so the next attempt doesn't repeat it.

This issue is two problems, and only one of them should be fixed

A — the double print. One item produces two scrollback lines (PASSED then ERROR, or . then E). Pure display concern. This is the bug.

B — the double count. The summary says 1 passed, 1 error for one item. This is arguably correct: pytest counts phase outcomes, and the item really did have a passing call and an erroring teardown. Changing it breaks CI parsers, assert_outcomes, and eleven years of expectation.

#14896 attempted B and left A untouched, which is the worst pairing — the printed lines then contradict the tally. Fix A. Keep B as it is.

The structural cause, and the hook that already exists

TerminalReporter.pytest_runtest_logreport is the only display driver and it is phase-shaped: it fires up to three times per item and writes immediately each time. Nothing in the reporter expresses "this item is finished".

Except pytest_runtest_logfinish does — it carries nodeid + location, and xdist already forwards it. So split the two jobs currently fused in logreport:

• accounting (stats, pytest_report_teststatus, -r sections) stays driven by logreport, per phase, unchanged;
• scrollback emission moves to logfinish, one line per item.

That fixes A, leaves the summary counts byte-identical, keeps third-party pytest_report_teststatus plugins working, makes the progress percentage actually mean "items finished / collected", and removes the need for the xdist past-edge hack from #7166 (each item emits exactly once, at its own logfinish, so nothing interleaves mid-item).

Target output

tests/test_api.py::test_ok   PASSED · teardown ERROR      [ 50%]
tests/test_api.py::test_bad  FAILED · teardown ERROR      [100%]
tests/test_api.py::test_s    ERROR (setup)                [ 75%]

The phase annotation is not decoration — it is what makes not changing the counts defensible. Once the line says the item passed and its teardown errored, 1 passed, 1 error is legible instead of mysterious.

Non-verbose single-char mode: emit the primary char only (E), not .E. Side benefit — the char count then equals the collected count, which is a long-standing source of confusion.

Two prerequisites, both worth separate PRs

1. Phase in the short summary. show_xfailed already renders XFAIL at teardown of test_foo, but show_simple (used for FAILED/ERROR) does not, so we emit a bare ERROR test_ok - ValueError: boom with no phase. Threading rep.when into _get_line_with_reprcrash_message is a handful of lines, count-compatible, and closes half of this issue on its own.

2. try/finally around logfinish. pytest_runtest_protocol currently has none, and Exit (always) plus KeyboardInterrupt (unless --pdb) propagate out of runtestprotocol per get_reraise_exceptions. Any logfinish-driven emission would silently drop the last item's line on Ctrl-C. This is a latent bug independent of this issue.

Where this should land: #14761, not the legacy reporter

The compat surface in the current TerminalReporter is large and the payoff here is one cosmetic line. #14761 is already committed to a second, opt-in, rich-based reporter — a compat-free greenfield where item-centric emission can simply be how it works.

rich's Live also resolves the one real cost of deferring to logfinish: today -v writes the nodeid before the result, so a hung test is identifiable; defer that and the terminal goes silent mid-item. A Live region gives that back, better:

tests/test_api.py::test_auth   FAILED · teardown ERROR     [ 43%]   <- scrollback
────────────────────────────────────────────────────────────────
 ⠹ gw0  tests/test_db.py::test_migrate    call      12.4s          <- live region
 ⠹ gw1  tests/test_api.py::test_retry     teardown   0.3s
   187/440  ━━━━━━━━━━━━╺━━━━━━  42%  · 180 passed 5 failed 2 error

logstart adds a row, logreport updates its phase label, logfinish drops it and prints the composed line above. The phase label pays off twice here: a test hanging in teardown versus in call is currently indistinguishable without faulthandler.

Two constraints for whoever picks that up:

• A Live region only works if every write to the terminal fd goes through one owner. Under -s, capsys.disabled(), or an fd-inheriting subprocess it will be shredded. Either gate Live on capture being enabled, or route uncaptured output through the reporter's console. --pdb/set_trace needs a hard stop-and-restart, and --log-cli/--setup-show must write through the same console.
• This is the same single-owner constraint the free-threading capture work already arrived at from the other direction, so the two should be designed together rather than in sequence.

Order matters: land item-centric emission without Live first, so the plain and CI paths are proven and this issue closes on its own terms. If Live lands first, item-centric emission looks like a Live implementation detail and gets entangled with tty detection — when it is precisely the part that has to work when there is no tty at all.

cc @lovetheguitar since you picked up #14761.

Analysis above produced with Claude Opus against the current tree, reviewed by me.