Opinion: When to (not) use fixtures for test data

[timhoffm]

I sometimes see people excessively using fixtures for test data even for trivial cases, e.g.

def my_list():
    return ["a", "b", "c"]

def test_list_len(my_list):
    assert len(my_list) == 3

def test_list_getitem(my_list):
    assert my_list[0] == "a"

IMHO this is an anti-pattern. There is little benefit in replacing one-liner data creation in tests (my_list = ["a", "b", "c"]) with a fixture. On the downside, the fixture adds indirection (harder to see what is happening) and coupling (if I want different data in a test, that may affect other tests). In these cases, people would be better off explicitly writing down the data in each test:

def test_list_len():
    my_list = ["a", "b", "c"]
    assert len(my_list) == 3

def test_list_getitem():
    my_list = ["a", "b", "c"]
    assert my_list[0] == "a"

Side-note: This pattern might have been learned from the very simplified examples in https://docs.pytest.org/en/7.3.x/how-to/fixtures.html#how-to-use-fixtures.

Question: Does pytest have an opinion on when to (not) use fixtures for test data? If so, I suggest we add that to documentation.

[RonnyPfannschmidt]

There's no official opinion

The reduced example you show unfortunately is a bit removed from practical use, the patterns looks similar to what Sometimes is used in university coursework

If you have links to public code affected we would have a better basis for discussion

[timhoffm]

Thanks for the reply. Unfortunately most code I see is confidential and cannot be shared. But the basic pattern is: You want to test a (standalone) class and instead of creating an instance at the beginning of each test, you inject the instance from a fixture, possibly even through a hierarchy of fixtures.

This is a public example of that pattern https://stackoverflow.com/questions/70622976/pytest-use-fixture-with-pandas-dataframe-for-parametrization. - It takes quite some effort to see why the test expects len(series) == 5.

[nicoddemus]

As @RonnyPfannschmidt said, there's no official advice, really depends on context.

My personal take is that the code is trivial, I tend to just write it in the test, instead of creating a one line fixture that, say, creates a class with a single parameter. As soon as that changes , or it is used in many more places, I tend to write a fixture for that -- as you mention, there is an indirection, but as with every design decision, there's a trade-off:

def test_x():
    f = Sample(value=25, unit="m", counts=80)
    ...

def test_y():
    f = Sample(value=25, unit="m", counts=80)
    ...

def test_z():
    f = Sample(value=25, unit="m", counts=80)
    ...

So you have this code creating Sample over dozens of files. As soon as you need to add a new parameter, you will have to fix all occurrences (of course you might get away with a simple find/replace, but often in complex cases it is not that simple). If you have that in a fixture, you have a single place to change.

I'm not trying to defend one way over another, just to illustrate that IMHO there's cases in cases for each approach.

[timhoffm]

Fully agree for the trivial case.

I still don't use fixtures to factor out pure test-data generation. While parametrization of fixtures is possible, a function def create_sample(value=25, unit="m", count=80) is simpler than a sample fixture.

In general, I would say that for test data generation that does not need any cleanup and does not have any across-test-shared state, a function is always simpler; i.e. rather than

@pytest_fixture
def sample_data():
    ...  # optionally use request param
    return data

def test_something(sample_data):
    ...

one should do

def create_sample_data([optional parameters]):
    ...
    return data

def test_something():
    sample_data = create_sample_data(...)
    ...

Fixtures begin to have advantages when you need session/module-level state or when you need to cleanup afterwards.

Would you agree on that?

[RonnyPfannschmidt]

Fixture Start to shine whenever resources and parameterization come into play

They don't really help much if all you do is created single data classes

Once one Starts to actually put together set's of element with possible required cleanup the scales tip