call to pytest_runtest_logreport is not proper

from _pytest/runner.py

def call_and_report(item, when, log=True, **kwds):
    call = call_runtest_hook(item, when, **kwds) 
    hook = item.ihook
    report = hook.pytest_runtest_makereport(item=item, call=call)
    #import pdb; pdb.set_trace()
    if log:
        hook.pytest_runtest_logreport(report=report) # -----> **this logreport has been overridden in our 
                                                                                               custom plugins** 
    if check_interactive_exception(call, report):
        hook.pytest_exception_interact(node=item, call=call, report=report)
    return report

for every test function , “pytest_runtest_logreport” is called after each of the setup/call/teardwon sections are executed. but during the teardown of the last test function:

   def teardown_exact(self, item, nextitem):
        needed_collectors = nextitem and nextitem.listchain() or []
        self._teardown_towards(needed_collectors)

nextitem is none [which is expected] so needed_collectors = []

In _teardown_towards function self.stack never gets equl to needed_collectors unless all the teardown functions are called, that is function , module and session . and after which the runtest_log_report is called . which is not the case if it were not the last test case.

def _teardown_towards(self, needed_collectors):
        import pdb; pdb.set_trace()
        while self.stack:
            if self.stack == needed_collectors[:len(self.stack)]:
                break
            self._pop_and_teardown()

due to this our reporting is getting impacted as we have overridden the pytest_runtest_logreport , please help here.

---

edited by @The-Compiler to add proper code formatting as this was unreadable otherwise 😉

[nicoddemus]

@gkambalu I see, thanks for confirming. I don’t think the current implementation is incorrect though, let me explain my reasoning:

pytest_runtest_logreport is used to report “setup”, “call” and “teardown” stages after the stage has been complete. This allows hook implementations to react to failure at any of those stages.

So the current sequence of events:

function fixture setup
module fixture setup
pytest_runtest_logreport -> "setup" for "test_foo.py::test_first"
...
function fixture teardown
module fixture teardown
pytest_runtest_logreport -> "teardown" for "test_foo.py::test_second"

“teardown” for "test_foo.py::test_second" is called only after all the fixtures which are part of its teardown process have also been finalized. This is important because module fixture might fail during “teardown”, allowing it to be properly reported.

Now if the teardown sequence was:

function fixture teardown
pytest_runtest_logreport -> "teardown" for "test_foo.py::test_second"
module fixture teardown

And module fixture fails during teardown, which hook would we call to inform hook implementations of that, given that the teardown stage of “test_foo.py::test_second” was already completed?

So the current implementation seems correct from my POV. I also understand your interpretation and it makes sense, but the current implementation also has logic behind it.

Having said that, I think you can obtain the behavior you want by using hookwrappers instead of plain hooks? For example using a hook wrapper around pytest_runtest_setup you can get called before any fixture is even created:

@pytest.hookimpl(hookwrapper=True)
def pytest_runtest_setup(item):
    # at this point no fixture was setup for `item` yet
    yield

pytest_fixture_setup and pytest_fixture_post_finalizer might also be helpful.

[nicoddemus]

Closing for now.