When to use pytest fixtures?

Asked 14/6, 2020 at 17:55 Answered 16/6 at 10:30

python python-3.x pytest fixtures pytest-fixtures

I'm new to testing and I've stumbled across pytest fixtures, but I'm not entirely sure when to use them and why they're useful.

For example, see the below code:

import pytest

@pytest.fixture
def input_value():
   input = 39
   return input

def test_divisible_by_3(input_value):
   assert input_value % 3 == 0

def test_divisible_by_6(input_value):
   assert input_value % 6 == 0

What is the function of the pytest.fixture here? Why can't we simply create a function called input_value() and run that function inside of the test function? For example:

import pytest

def input_value():
   input = 39
   return input

def test_divisible_by_3():
   assert input_value() % 3 == 0

def test_divisible_by_6():
   assert input_value() % 6 == 0

Why can't we just do this? What's the use of using fixtures?

Triacid answered 14/6, 2020 at 17:55 Comment(3)

pytest fixtures are a generalized way to set up/tear down a test case or a test suite, your example it indeed doesn't make much of a difference between a fixture and a regular function. Did you read through pytest fixtures: explicit, modular, scalable? This should give you an overview of what is possible to do with fixtures. – Helsie 14/6, 2020 at 19:58

I can only agree with the question: pytest fixtures seem to be a re-invention of existing language features, actually introducing redundancy and complexity, making things harder rather than easier. Python itself is explicit, modular and scalable already, so why not just use these features also for test fixtures? – Hite 26/3, 2022 at 13:15

I'd go even further than OP: Why do we need functions at all, whether they're fixtures or regular functions, if all they're doing is returning a static value? In OP's example above, wouldn't it be cleaner to get rid of input_value() altogether and just define a global variable (eg. INPUT = 39) that you can then use as input to your test functions like any other argument (eg. def test_divisible_by_3(input_value=INPUT):)? – Mocha 17/5, 2022 at 20:56

Both Pytest Fixtures and regular functions can be used to structure to test code and reduce code duplication. The answer provided by George Udosen does an excellent job explaining that.

However, the OP specifically asked about the differences between a pytest.fixture and a regular Python function and there is a number of differences:

Pytest Fixtures are scoped

By default, a pytest.fixture is executed for each test function referencing the fixture. In some cases, though, the fixture setup may be computationally expensive or time consuming, such as initializing a database. For that purpose, a pytest.fixture can be configured with a larger scope. This allows the pytest.fixture to be reused across tests in a module (module scope) or even across all tests of a pytest run (session scope). The following example uses a module-scoped fixture to speed up the tests:

from time import sleep
import pytest


@pytest.fixture(scope="module")
def expensive_setup():
    return sleep(10)

def test_a(expensive_setup):
    pass  # expensive_setup is instantiated for this test

def test_b(expensive_setup):
    pass  # Reuses expensive_setup, no need to wait 10s

Although different scoping can be achieved with regular function calls, scoped fixtures are much more pleasant to use.

Pytest Fixtures are based on dependency injection

Pytest registers all fixtures during the test collection phase. When a test function requires an argument whose name matches a registered fixture name, Pytest will take care that the fixture is instantiated for the test and provide the instance to the test function. This is a form of dependency injection.

The advantage over regular functions is that you can refer to any pytest.fixture by name without having to explicitly import it. For example, Pytest comes with a tmp_path fixture that can be used by any test to work with a temporary file. The following example is taken from the Pytest documentation:

CONTENT = "content"


def test_create_file(tmp_path):
    d = tmp_path / "sub"
    d.mkdir()
    p = d / "hello.txt"
    p.write_text(CONTENT)
    assert p.read_text() == CONTENT
    assert len(list(tmp_path.iterdir())) == 1
    assert 0

The fact that users don't have to import tmp_path before using it is very convenient.

It is even possible to apply a fixture to a test function without the test function requesting it (see Autouse fixtures).

Pytest fixtures can be parametrized

Much like test parametrization, fixture parametrization allows the user to specify multiple "variants" of a fixture, each with a different return value. Every test using that fixture will be executed multiple times, once for each variant. Say you want to test that all your code is tested for HTTP as well as HTTPS URLs, you might do something like this:

import pytest


@pytest.fixture(params=["http", "https"])
def url_scheme(request):
    return request.param


def test_get_call_succeeds(url_scheme):
    # Make some assertions
    assert True

The parametrized fixture will cause each referencing test to be executed with each version of the fixture:

$ pytest
tests/test_fixture_param.py::test_get_call_succeeds[http] PASSED                                                                                                                                                                         [ 50%]
tests/test_fixture_param.py::test_get_call_succeeds[https] PASSED                                                                                                                                                                        [100%]

======== 2 passed in 0.01s ========

Conclusion

Pytest fixtures provide many quality-of-life improvements over regular function calls. I recommend to always prefer Pytest fixtures over regular functions, unless you must be able to call the fixture directly. Directly invoking pytest fixtures is not indended and the call will fail.

Viafore answered 21/5, 2021 at 11:44 Comment(5)

I don't see the quality-of-life improvements in fixtures, just the additional effort needed to get them to work. For example, referring to a fixture without having to import it is worse, code is organised into modules for a reason; this also defeats autocompletion and type checking. Parametrisation can be done by passing the test's arguments to a regular function. Scope can be achieved with classes or module-global variables. Is there a drawback of regular functions that I'm missing? – Amylolysis 20/1, 2022 at 9:28

You can achieve the same functionality without pytest. Also you don't have to make use of all features, like autouse fixtures. If it works better for you to use regular functions: go for it It's worth mentioning, though, that you might end up building your own testing framework. Developers new to your project will have to spend time learning your framework, whereas pytest is widely known already [1][2]. pytest also has other cool features besides fixtures :) [1] jetbrains.com/lp/python-developers-survey-2019 [2] jetbrains.com/lp/python-developers-survey-2020 – Viafore 21/1, 2022 at 10:16

"The advantage over regular functions is that you can refer to any pytest.fixture by name without having to explicitly import it". When looking at other peoples code it makes tracking down where a fixture is defined harder. – Anxious 12/8, 2022 at 10:14

> "This allows the pytest.fixture to be reused across tests in a module (module scope) " This was already supported before fixtures: to get a module scope you put a setup() and teardown() at the top of the file; to get a session scope you put them in the __init__.py. It was far clearer. – Inobservance 29/6, 2023 at 15:0

"initializing a database", using a persistent test database across different tests is a recipe for disaster – Pricillaprick 8/8, 2023 at 14:55

New to pytest myself but I know it reduces the need to write code that is used by multiple tests multiple times as in this your case you would have needed to rewrite that function severally, and this snippet would be a starter:

Fixtures are used to feed some data to the tests such as database connections, URLs to test and some sort of input data.

Therefore, instead of running the same code for every test, we can attach fixture function to the tests and it will run and return the data to the test before executing each test.

-- Source: https://www.tutorialspoint.com/pytest/pytest_fixtures.htm

Generally it helps to share resources among your tests that are common to them and greatly reduces duplication. Again the return values from these fixture functions can be passed as 'input parameters' into the individual tests as seen here:

@pytest.fixture
def input_value():
   input = 39
   return input

def test_divisible_by_3(input_value):
   assert input_value % 3 == 0

Secundas answered 14/6, 2020 at 18:4 Comment(7)

we can also write fixtures once in a separate module and reuse them everywhere without importing which is a great thing because we are separating arguments and their creation from test scenarios and tested API – Benzoate 14/6, 2020 at 18:22

What do you mean by I'd need to rewrite that function several times? I'd only need to write it once and then call it within the test functions? – Triacid 14/6, 2020 at 18:36

I that is the point I am trying to make you don't need to do so with fixtures! – Secundas 14/6, 2020 at 18:43

But why use a pytest fixture? Why can’t we just define a normal function with the same return as the pytest fixture? – Triacid 14/6, 2020 at 19:53

Same question as @theman, why? Without @pytest.fixture, a normal function can do, and can be shared reused as well. I googled around but still little of them explaining why not using a normal function to share data inputs. – Argyres 19/3, 2021 at 21:46

Agreed, came here because of the exact same question. Sharing fixtures amongst tests is a proper reason, as you can share a function just as easy. I guess what pytest is doing, is to run the fixture, save the return value and just reuse that instead of having to rerun the function every time it is used. – Hegyera 30/9, 2022 at 13:10

IMHO the fundamental difference is when the fixture is used to initialize some state (say, populating a table in a database) and then tear that down after the test is run. If the fixture is just computing something, then indeed it has no fundamental advantage over functions. – Fong 20/5, 2023 at 0:43

A fixture is used:

to have a specific function to be used many times and to simplify a test.
to do something before stating and after finishing test with yield.

For example, there are test_get_username() and test_set_check_password() in Django as shown below:

import pytest

from django.contrib.auth.models import User

@pytest.mark.django_db
def test_get_username():
    user = User.objects.create_user("test-user")
    user.username = "John"
    assert user.get_username() == "John"

@pytest.mark.django_db
def test_set_password_and_check_password():
    user = User.objects.create_user("test-user")
    user.set_password("new-password")
    assert user.check_password("new-password") == True

Then, you can create and use user() with @pytest.fixture to use it many times and to simplify test_get_username() and test_set_password_and_check_password() as shown below:

import pytest

from django.contrib.auth.models import User

@pytest.fixture # Here
def user():
    user = User.objects.create_user("test-user")
    return user

@pytest.mark.django_db
def test_get_username(user): # <- user
    user.username = "John"
    assert user.get_username() == "John"

@pytest.mark.django_db
def test_set_password_and_check_password(user): # <- user
    user.set_password("new-password")
    assert user.check_password("new-password") == True

And, for example, there are fixture_1() with yield and test_1() as shown below:

import pytest

@pytest.fixture
def fixture_1():
    print('Before Test')
    yield 6
    print('After Test')

def test_1(fixture_1):
    print('Running Test')
    assert fixture_1 == 6