Replies: 1 comment
|
Hi @ws1088 The fundamental limitation is timing:
So a fixture cannot return a list at runtime and then ask pytest to retroactively create one independent test item for every returned value. If the objects can be discovered during collection, move that discovery into If the objects genuinely cannot be known until the live fixture is running, keep a runtime loop instead. On current pytest, the built-in def test_server_objects(server_objects, subtests):
for obj in server_objects:
with subtests.test(id=obj.id):
assert obj.is_valid()That gives each runtime object a separately reported subtest instead of aborting the whole loop on the first failed assertion. The tradeoff is that these are subtests, not normal collection-time parametrized node IDs, so they do not have exactly the same individual selection semantics as Please mark this answer as accepted if it helped, thank you. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
I am facing exactly the same situation as the poster of: https://stackoverflow.com/questions/54105134/pytest-fixture-with-parametrization-from-another-fixture
And I also search a lot of places and couldn't find a good answer. I wonder if anyone has come across the same problem and has found a good solution?
Thanks!
All reactions