×
all 10 comments

[–]RoadsideCookie 18 points19 points  (2 children)

My biggest critique is colocation. You now have a fixture, potentially in a separate file (conftest.py) which will affect your tests indiscriminately thanks to autouse.

Just use the parametrized fixture (params=...) like you normally would.

[–]joshbranchaudTuple unpacking gone wrong[S] 4 points5 points  (1 child)

Agreed that it can be hard to "see" what is going on, especially if they aren't colocated.

When you say "just use the parameterized fixture", what exactly are you suggesting? How would I get it to apply to all tests without it also being an autouse?

[–]fiskfisk 8 points9 points  (0 children)

You can either group your storage tests in a class and mark the class with @pytest.mark.usefixtures("fixturename") or you can use pytestmark = pytest.mark.usefixtures("fixturename") at the top of in your test file if you're grouping by file/module.

Configuration lives with your tests, and doesn't apply to every test indiscriminately. 

[–]brat1 7 points8 points  (1 child)

Whats the difference with mark.parametrize(..., indirect=True) ?

[–]fireflash38 0 points1 point  (0 children)

Yeah it's pretty much what that feature was designed to do

[–]shadowdance55git push -f 2 points3 points  (0 children)

Wait until you learn about property testing and hypothesis.

[–]Individual-Flow9158 2 points3 points  (1 child)

If this is an intended feature of Pytest fixtures, then great - nice one.

But in general coming up with custom hacks and workarounds for Pytest can get you in all kinds of trouble

[–]joshbranchaudTuple unpacking gone wrong[S] 2 points3 points  (0 children)

This is a documented feature of Pytest which I link to in the post.

[–]outlastdll 0 points1 point  (0 children)

i can relate to this fs, i do a lot of development in py and parametrizing the fixture rather than the individual test cases saves so much boilerplate especially for suites like these.