-
-
Notifications
You must be signed in to change notification settings - Fork 18.4k
REF/TST: Stop using singleton fixtures #24769
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@jbrockmendel : Indeed, too bad we can't lint these very easily AFAICT... |
The test failures look very weird to me. @gfyoung any ideas? |
@jbrockmendel : I see only one test failure regarding your refactoring of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
really? this is the entire point of fixtures. pls show an example of how this actually helps
key poiint. IF its truly a singleton. These are used all over the place, or at least should be. There are many many other files that actually just use TestData that should simply use these fixtures. They just have not been converted. |
Are you two using different definitions of singleton? @jbrockmendel's is (roughly, ignoring things like setup / teardown that don't apply to these), "a non-parametrized fixture". In this case, using a helper method in @jreback's definition might be "a fixture that's only used in a single test"? |
@TomAugspurger thanks, I think you've got it right on the terminology mismatch. Even if a fixture is used in many places, for one-liners or otherwise non-parametrized fixtures, we're better off inlining or putting them in pd.util.testing like this PR does. We get improved copy/paste-ability, reduce pytest lockin, and improve clarity. As a reader, which of these is clearer:
I claim the latter is clearer by a wide margin. |
Codecov Report
@@ Coverage Diff @@
## master #24769 +/- ##
==========================================
+ Coverage 92.38% 92.39% +<.01%
==========================================
Files 166 166
Lines 52363 52400 +37
==========================================
+ Hits 48377 48413 +36
- Misses 3986 3987 +1
Continue to review full report at Codecov.
|
Codecov Report
@@ Coverage Diff @@
## master #24769 +/- ##
==========================================
+ Coverage 92.38% 92.39% +<.01%
==========================================
Files 166 166
Lines 52402 52439 +37
==========================================
+ Hits 48414 48450 +36
- Misses 3988 3989 +1
Continue to review full report at Codecov.
|
if the only change to this test is replacing the fixture then it could be a change to N or K in tm. |
in cases like this |
I can't reproduce this locally. Can anyone else? |
If somehow the test behavior depends on whether a fixture is used, that would be troubling |
Interestingly, it seems to be a flaky test
Just had 6/100 fail. |
On the PR itself, I personally don't care about copy/paste-ability, and am not too concerned with pytest lock-in. I do care about how long the test suite takes, so reducing that without sacrificing readability / maintainability is a win. And to me, a simple fixture that just provides a value (no setup / teardown) is equivalent to a method call inside the test. |
i am -1 on this change - this goes against the entire maxim of using fixtures this just puts more distance between what is being tested and construction this is just reinventing the pytest and is a giant leap backwards |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as commented
How are you measuring distance? It's just a function call either way. And, depending on your editor, this may be less "distance" since goto definition typically works for function calls, but not necessarily for fixtures. |
Um... the opposite of that. In many cases the way the PR does it doesn't even have to call into What it does do is decrease the ambiguity about where something is defined.
Since when did pytest invent inlining code or function calls? By this logic, every object we use in more than one test should be made into a fixture. Where would you draw the line and why?
For the places where the fixtures are inlined instead of moved into
I find the readability strictly improved by this. It also makes it easier to figure out what refactoring opportunities are available, which has other maintainability/perf upside. In the status quo there are a handful of fixtures in |
Just to be clear, I was talking about reduced setup time from avoiding fixtures (btw, do you have rough at how much this shaves off? I suppose a |
N=5 they are indistinguishable. Incidentally, for me the collection takes about 12% of test runtime (with parallelization). I think some of the way to cut down on that is to push back on over-parametrization. |
just had this ci failure..
so I think that tm.N and tm.K take on different values depending on the order that the tests are run. |
Seems like we have tests that set those, which seems iffy
|
@TomAugspurger agreed that altering tm.K and tm.N is not great. But I don't see how that would change the affected test's behavior, do you? |
float-frame defined in function..
float-frame fixture..
change code to ...
so it appears to be due to re-use of memory space after dereferencing |
@jreback @jbrockmendel @simonjayhawkins I haven't touched these issues that much anymore, since it was supposed to be a "good first issue" (and had some response along those lines for a while), and I was busy with other PRs. |
100/100 pass rate with
also with holding a reference to original object
|
Is this on a platform/version that was previously failing? we've still got three failing builds |
yes, i'm running locally on windows and getting failures with a copy of your branch.
four methods of preventing dereferencing always pass. fixture, @pytest.mark.parametrize, assigning original object to another variable and using different variable for the copy. before the fixture was created, the float-frame object would have been created outside the function. so it makes sense that before the fixture was created that a reference would have been kept to the float-frame object and the test passed. |
Thanks for digging into this.
I think I follow. For the time being I'm going to use the |
Found when trying to collect reduction tests that we are still using a lot of singleton fixtures (agreed undesirable in #23701). This gets rid of singleton fixtures in tests.frame
Following this it will be easier to more usefully parametrize some of those tests.