Potential for Optimization of Fixture Teardown

Dear pytest developers,

I think there is potential for optimization of fixture teardown. The idea is probably best explained with an example. Consider the file test_teardown.py:

import pytest

@pytest.fixture(scope='module')
def a():
    return "a"

@pytest.fixture(scope='module')
def b():
    return "b"

def test_a(a):
    assert a == 'a'

def test_b(b):
    assert b == 'b'

def test_c():
    assert True

To see when fixtures are set up and torn down, it can be run as follows:

pytest --setup-show test_teardown.py

This produces the following output

test_teardown.py 
    SETUP    M a
        test_teardown.py::test_a (fixtures used: a).
    SETUP    M b
        test_teardown.py::test_b (fixtures used: b).
        test_teardown.py::test_c.
    TEARDOWN M b
    TEARDOWN M a

Both fixtures are initialized lazily, i.e. set up when they are needed. But they are kept around for longer than necessary. Specifically, fixture a could be destroyed after test_a has been run since no future test relies on it. Similarly, fixture b could be torn down after test_b has been run, since test_c does not need it.

This information could be inferred at runtime by inspecting the dependency tree (which should be quick).

I am assuming that right now, fixtures are torn down whenever the applicable scope ends (in this case when all the tests in the module have been run).

Optimizing fixture teardown to occur whenever the fixture is no longer required would be beneficial in situations where fixtures hold on to considerable resources (e.g. computer memory). There are possibly other ways the user can remedy these situations but this optimization seems to be an easy way to mitigate some of these problems automatically.

I am using pytest 3.7.1 on Python 3.6.5 and MacOS High Sierra (python installed via homebrew).

Please let me know what you think about this!

Thank you,

Michael

Start with the example in test_teardown.py and run pytest --setup-show test_teardown.py to verify the current fixture lifecycle. Read the fixture dependency and scope behavior involved in determining when a fixture is no longer required. Done should include a defined teardown policy and coverage showing that fixtures are released at the proposed earlier points without breaking dependent tests.