Allow wildcard in test dependencies about lemoncheesecake HOT 7 CLOSED

In that case, you could use the dynamic test generation feature: https://docs.lemoncheesecake.io/en/latest/generated.html

While it is not (yet) documented in https://docs.lemoncheesecake.io/en/latest/api.html#lemoncheesecake.api.Test , when you create a lcc.Test instance you can also play with its dependencies attribute that is a list of test paths it depends on (like the depends_on() decorator). If you take the examples of https://docs.lemoncheesecake.io/en/latest/generated.html, for each PARAMETERS you would generate two tests, the second one depending on the first one.

Do you see how to it works or do you need more explanations ?

from lemoncheesecake.

Hello @tardigradeus ,

You're right, there is some room for improvements on this mechanism. I already have some ideas in mind on this topic for the future.

Waiting for this, your "ugly trick" could be a little less "ugly" / shorter ;-) :

@lcc.depends_on(*[f"test_a_lot_of_stuff_{i+1}" for i in range(len(PARAMETERS))])

Regards,

Nicolas.

from lemoncheesecake.

Thanks for your reply and your tip,

Nice to hear that you have ideas about this feature.

I don't know if you already had the idea in mind, but it could be really great if a test is linked to a previous test by the ID like:

PARAMETERS = (
{"profile": "profile1"},
{"profile": "profile2"},
{"profile": "profile3"},
....
{"profile": "profileN"}
)

@lcc.test("First test")
@lcc.parametrized(PARAMETERS)
def init_profile(profile): 
 # Do Test

@lcc.test("Second test")
@lcc.depends_on(@lcc.depends_on(*[f"init_profile{i+1}" for i in range(len(PARAMETERS))]))
@lcc.parametrized(PARAMETERS)
def test_other_stuff(profile):
 # Do Test

And if the init_profile_3 test fails test_other_stuff will not be launched at all, it would be great to launch every other test appart test_other_stuff_3

from lemoncheesecake.

Erratum on:

@lcc.depends_on(*[f"test_a_lot_of_stuff_{i+1}" for i in range(len(PARAMETERS))])

The arguments of @lcc.depends_on() must be the full path of the tests (including the parent suite(s) name(s)), so it would be more like this:

@lcc.depends_on(*[f"your_suite_name.test_a_lot_of_stuff_{i+1}" for i in range(len(PARAMETERS))])

I try to understand what you want to do, do you want to do something like this:

• test_other_stuff_1 only depends on init_profile_1
• test_other_stuff_2 only depends on init_profile_2
• test_other_stuff_3 only depends on init_profile_3
• etc...

?

from lemoncheesecake.

No worries, in my first message i just forgot to add the suite name but we have it.

Yes exactly, but in an implicit way without the need to declare every dependency, maybe with a special syntax or parameter in the depends_on.

from lemoncheesecake.

Nice feature, I think i got the gist of it, the documentation seems clear to me, we will keep that in mind and test it in a near future.
Should i close the issue now ?

from lemoncheesecake.

Yes, I let you close the ticket.

To say a few words about what I have in mind about @lcc.depends_on(): the idea would be to accept a callable that would express as a "filter" the test it depends on.
You would be able to express this:

@lcc.depends_on(*[f"your_suite_name.test_a_lot_of_stuff_{i+1}" for i in range(len(PARAMETERS))])

as this:

@lcc.depends_on(lambda test: test.path.startswith("your_suite_name.test_a_lot_of_stuff_"))

For the case you want to handle, it wouldn't help. The test generation mechanism is the best solution for your need.

from lemoncheesecake.