Can't pytest fixtures observe the exception?

[eekcoopuw]

I have a pytest fixture, written in "yield fixture" style, that wants to observe a test failure in order to do extra reporting.

In particular, my fixture is setting up a temporary directory, and if there's a failure in the test, I want it to print the contents of that directory so I can see more of what was and wasn't created in there during the test.

But it seems like exceptions get swallowed before coming out of the "yield" of a yield-style fixture; is that right? I see this old bug thread that suggests so: #2508 But I don't see anything corroborating that in the current docs https://docs.pytest.org/en/stable/how-to/fixtures.html so I wasn't sure.

It's a pity because in fact I'm using a context manager defined elsewhere, that doesn't know it's in a test. My fixture looks like this:

@pytest.fixture
def foo_fs(tmpdir: str) -> Generator[FileSystem, None, None]:
    fs = FooFileSystem(path_prefix=Path(tmpdir))
    with _temporary_filesystem(fs, tmpdir):
        yield fs

So that "temporary filesystem" helper, which is what tries to catch, print something, and rethrow the exception, is not wise to the fact that it's inside a pytest fixture, and it would be a pity to rewrite it.

Is it really not possible to pass the exception to the fixture?

[The-Compiler]

This is intended, otherwise every single fixture would need to handle a failing test manually somehow.

You could probably do something clever with hooks, but what I'd do in your case is just printing the information either way - pytest's capturing will only show it for failing tests by default.

[RonnyPfannschmidt]

I wonder if it would be possible to provide an builtin fixture that provides a exception in teardown for failed tests

It could have apis for providing safe/unsafe raised exceptions as reraising may alter them unintentionally

[eekcoopuw]

OK, thanks for the quick reply! I see the difficulty that some fixtures would want this behavior and others wouldn't.

@The-Compiler Yes, I think printing the info either way is the most expedient solution for my case.

If the current behavior isn't mentioned in the docs somewhere, it probably should be! It was a bit of a surprise to me that my context manager's error handler wasn't being invoked.