Hi James,
What I suggest you do in your case is to decouple your code from the
fixture, so if you have something like this today:
@pytest.fixture(scope="module")
def my_work_reqs():
# some
# complicated
# setup
# code
yield x # some result
# some
# complicated
# teardown
# code
You can write instead:
@contextmanager
def handle_work_reqs():
# some
# complicated
# setup
# code
try:
yield x # some result
finally:
# some
# complicated
# teardown
# code
@pytest.fixture(scope="module")
def my_work_reqs():
with handle_work_reqs() as x:
yield x
Now you can test handle_work_reqs normally, as it is not tied to the pytest
framework.
I like this approach in general, decoupling custom code from a framework is
a great way to make it easier to test.
HTH,
Bruno.
On Wed, Jan 6, 2021 at 2:37 PM James Cooke <m...@jamescooke.info> wrote:
> Hi all,
>
> It's been a while since I've had to write a complicated and robust pytest
> fixture and I'm struggling with testing the teardown / finalisation code.
>
> Instead of boring you with the [my-work-project] requirements of cleaning
> up GCS after tests, I'll refer to the fixture in the docs
> https://docs.pytest.org/en/stable/fixture.html#fixture-finalization-executing-teardown-code
> :
>
> @pytest.fixture(scope="module")
> def smtp_connection():
> smtp_connection = smtplib.SMTP("smtp.gmail.com", 587, timeout=5)
> yield smtp_connection # provide the fixture value
> print("teardown smtp")
> smtp_connection.close()
>
> My (very old) usual strategy for testing teardown of a fixture that uses
> `yield` would be:
>
> * Start test
>
> - Instantiate the fixture.
>
> - Manipulate the instance with `next()` to trigger the teardown.
>
> - Ensure that teardown was successful - in this case assert that the
> SMTP connection returned when the fixture was instantiated was closed
> successfully.
>
> Given that since v4.1 (https://github.com/pytest-dev/pytest/issues/4545),
> the arrangement step of "Instantiate the fixture" does not work, could
> someone point me at the recommended method of testing fixture teardown?
>
> I would like to ensure that teardown is resilient and can resolve multiple
> conditions that can happen in [my-work-project]'s test suite. I can see
> that there are multiple tests on fixtures in
> https://github.com/pytest-dev/pytest/blob/48c9a96a03261e7cfa5aad0367a9186d9032904a/testing/python/fixtures.py
> , are there any preferred / recommended / efficient methods in this file?
> Alternatively, is there a way to by-pass the fixture wrapping that happens
> that prevents it being callable? Should I be using
> `smtp_connection.__pytest_wrapped__.obj()` to instantiate? (this seems bad)
>
> Any pointers / suggestions would be great.
>
> Thanks,
>
> James
>
>
> _______________________________________________
> pytest-dev mailing list
> pytest-dev@python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
_______________________________________________
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev
