Pytest: test only one instance of parametrized fixture

user_14099195 0
Viewed 1356

Setting

Suppose I have conftest.py where I defined resources for tests

class ClassifyRequest:
    pass

class OCRRequest:
    pass

@pytest.fixture(params=[ClassifyRequest, OCRRequest])
def api_request(request):
    return request.param()  # return one of the request instances

Then, in test_api.py I use the parametrized fixture to test a service:

def test_service(api_request):
    response = send_request(api_request)
    assert response.ok()

All good, but then I want to test specialized fixture api_request[ClassifyRequest]:

@pytest.mark.usefixture("api_request[ClassifyRequest]")
def test_classification():
    # do something with the api_request fixture

Question

What is the way to specialize a parametrized fixture for a test function? I have two ideas:

  1. Just use a non-parametrized fixture. This inevitably leads to boilerplate code.
  2. Remove explicit parametrization from the fixture decorator and use indirect parametrization like 
    @pytest.mark.parametrize("response_class", ["classify", "ocr"])
def test_api(api_request):
    # do smth
    Replacing class parameters with strings equals creating two sources of configuration. What if I want to add another parameter? Do I have to design a new string for it, as well as instantiate an object inside api_request fixture indirectly?
  3. The same, except keep class parametrization and move classes outside conftest.py as pytest can't import names from that module with import statements.

Additional info

pytest==6.0.1

pytest python
3 Answers

If all your fixture does is instantiation, I'd opt for parametrizing the test, not the fixture. But, well, if you have to and specialize it manually anyway, you could simply add a wrapper to make the fixture callable:

import pytest
import types

class ClassifyRequest:
    def __init__(self):
        print("ClassifyRequest ctor")

class OCRRequest:
    def __init__(self):
        print("OCRRequest ctor")

def api_request_wrapper(request):
    return request.param()  # return one of the request instances

@pytest.fixture(params=[ClassifyRequest, OCRRequest])
def api_request(request):
    return api_request_wrapper(request)

def test_classification():
    request = types.SimpleNamespace()
    request.param = ClassifyRequest
    instance = api_request_wrapper(request)

Seems a bit hacky, though.

user_54308330

What you are trying to achieve is to create test case filtering rules. The best place to do that is via the "pytest_collection_modifyitems" hook in Pytest.

This hook will be called once all the tests are collected from the path you give as input to Pytest.

You can put your logic in this hook.

Its always a best practice to associate an ID along with your parameters like below:

@pytest.fixture(params=[ClassifyRequest, OCRRequest], 
                ids=['ClassifyRequest', 'OCRRequest'])
def api_request(request):
    return request.param()  # return one of the request instances

Once you have this, your testcase will be generated as test_classification[ClassifyRequest] and test_classification['OCRRequest']..

If you are running specific set of tests and want the filtering to apply on all the tests, then -k option itself will suffice.

But since here its only on a subset of tests you want to apply the rule, the hook definition can be in the module where the test is present.

user_75343490

Note: this is an preliminary conclusion, I created an issue on pytest Github to see the community's opinion on this topic.

I think the cleanest way to implement the desired specialization is to move the request classes to a separate module and use conftest.py to declare fixture functions only. According to pytest documentation,

If during implementing your tests you realize that you want to use a fixture function from multiple test files you can move it to a conftest.py file.

If you want to make test data from files available to your tests, a good way to do this is by loading these data in a fixture for use by your tests.

This way I can import classes in test modules and parametrize the fixture indirectly through test functions. In my case request classes are very easy to instantiate, so there's no need for a separate fixture for each class, only the aggregate. But generally, it's ok to define a fixture for each resource and an aggregate parametrized fixture.

user_140991950
Related