how to handle acyclic pattern for test case generation?

[sandeep-gh]

Best, I can explain this with example.

@pytest.fixture(name="classType", params=["passive", "active", "mutable"])
def _classType(request):
    return request.param

@pytest.fixture(name="container", params=[None, "static", "mutable"])
def _container(request):
    return request.param

@pytest.fixture
def  all_cases( classType, container):
    # generate object based on classType, container
    return classType, container, <generated-object>

@pytest.fixture
def  subcases_1( all_cases):
    classType, container, <generated-object> = all_cases
    # filter cases based on some criteria
    return  classType, container, <generated-object>

@pytest.fixture
def  subcases_2( all_cases):
    classType, container, <generated-object> = all_cases
    # filter cases based on some criteria
    return  classType, container, <generated-object>


def test_x(subcases_1, subcases_2):
    # Not working as expected 
   #  no cases generated

there are no cases in subcases_2 and hence there are no test to run in test_x. My usage is bit involved with subcases of subcases and that tree going a bit deep. Any ideas would be of great help. Thanks.

[RonnyPfannschmidt]

the example is absolutely unclear as to what the desired use case and behaviour is to anyone lackaing the background knowledge of your particular problem domain

please elaborate what cases are and how they are supposed to interact

[sandeep-gh]

Thank you taking a look. I will try to explain. . The application code deals with generating json that would be finally be rendered as webpage by browser runtime. The application code is required to find the changed diff and report to the frontend browser. There are 3 class type "passive", "active" and "mutable". Unlike mutable, Passive/active never change.

The classesare further classified bases on containment property: which is "none", static, "mutable". None implies it class does not act as container. Static implies contains only static objects. "mutable" implies it can contain both static and mutable objects. All this class generation is for efficiently retrieving changed diff.

So, in the test: fixture all_cases generates all permutation/combination of various class types. Now, rest of the fixtures, essentially filter based on some classType or containment criteria from the classes generated from fixture all_cases.

Finally, I am creating tests that take two filtering fixtures: one for container class types, and another non-container and creates instances and tests operations on those instances.

my guess is that since pytest is iterator based, the fixture exhausts all the cases generated from all_cases, resulting is second fixture to have none of the cases.

I don't have to stick to this pattern of test setup. I am open using other patterns that would address this issue.

[RonnyPfannschmidt]

I believe you completely misunderstood how Parameters work

They get expanded once per test function,im under the the impression you want to use the parameters in 2 ways and need to use different Parameters for that

[sandeep-gh]

I am realizing that now. Given all the slice and dice I have to do over all the cases and the various permutation and combinations i need to generate, creating different Parameters/fixture would make things quite messy. Maybe I should explore some other framework, pytest is not suited for this.

[The-Compiler]

I don't see why pytest wouldn't be suitable for this. It offers a lot of different ways on how to parametrize things.

[sandeep-gh]

Its not about parameterization, per se. If I understand correctly, the main issue is the fork-join pattern of fixtures. There is a base fixture which generates all the test cases. Then there are two fixtures F1 and F2, derived from base fixture that filter different sets of test cases. Now, there is a test that depenends on both F1 and F2. Since, pytest is based on iteration (my guess), either F1 or F2 will have empty number of test cases.

I am trying to avoid creating tons of base cases one for each final set of test cases required. It will be more efficient but way to verbose.

[RonnyPfannschmidt]

Pytest has native cross product support and is not based on iteration

Your setup it's Just completely wrong

[sandeep-gh]

Was able to solve this. Essentially, I shouldn't be using fixtures to create parameters. The new approach looks as follows:

@pytest.fixture(name="HCCMutableTypes_NoStub",
                params=[_ for _ in generate_ClassTypes(DivMixins,
                                           ["passive", "active", "mutable"],
                                           ["mutable"]
                                           )
                        ]
                )
def _HCCMutableTypes_NoStub(request):

Maybe there is some value in having fixture like expression for parameter generation . They fixture-style expressions are much cleaner and succient. Thanks for chiming in the discussion. It helped.