[pytest-dev] Testing fixture teardown / finalisation

[Floris Bruynooghe]

Hello,

I can recommend both Bruno's and Florian's approaches as being good
practice :)

Cheers,
Floris

On Thu 07 Jan 2021 at 18:11 +0100, Florian Bruhin wrote:

> 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