Hey, On Wed, Jan 06, 2021 at 03:26:08PM -0300, Bruno Oliveira wrote: > What I suggest you do in your case is to decouple your code from the > fixture, so if you have something like this today: > > [setup / teardown in a fixture] > > You can write instead: > > @contextmanager > def handle_work_reqs(): > # [setup] > try: > yield x # some result > finally: > # [teardown] > > @pytest.fixture(scope="module") > def my_work_reqs(): > with handle_work_reqs() as x: > yield x
Perhaps it's just as obvious (at least in hindsight), but explicit is
better as implicit:
Another thing I often do is return some kind of custom class from the
fixture, which tests can use - let's say we have:
class JSTester:
def __init__(self, qtbot):
self.qtbot = qtbot # a fixture needed in the class
def run(self, source):
# ...
# [some other methods tests can use]
@pytest.fixture
def js_tester(qtbot):
return JSTester(qtbot)
So that the tests can do things like:
def test_simple_js(js_tester):
js_tester.run('1 + 1')
If there was some teardown to do here, I'd just add a "cleanup" method
to that class, and call that in the fixture.
If, for some reason, you have some more complex scenario and want to
test it inside pytest rather than isolated from it, another possibility
is the pytester fixture (called testdir in earlier releases):
https://docs.pytest.org/en/latest/writing_plugins.html#testing-plugins
https://docs.pytest.org/en/latest/reference.html#std-fixture-pytester
Florian
--
m...@the-compiler.org (Mail/XMPP) | https://www.qutebrowser.org
https://bruhin.software/ | https://github.com/sponsors/The-Compiler/
GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc
I love long mails! | https://email.is-not-s.ms/
signature.asc
Description: PGP signature
_______________________________________________ pytest-dev mailing list pytest-dev@python.org https://mail.python.org/mailman/listinfo/pytest-dev
