This polly is closed. <@U01PZK60W2F> has a polly f...
# development
s
This polly is closed. @curved-television-6568 has a polly for you!
c
It is about using a plain class, not one based on
TestCase
.
g
I've never used a class for a test outside of niche cases like class-scoped fixtures etc. Generally with other plugins as well to ensure a specific sequence, and so on. I don't really see a need beyond that, it just seems noisy to me.
c
yea, I've not missed the classes when I made the switch from unittest to pytest myself either.. I can see however a few of the test files in pants are rather long, and having them grouped into sections using classes I think could be a nice way to manage that. Either way, this poll is meant to gain consensus on what stand we want to take here, so we can add this to the style guide as a do or don't do. 😉
h
I personally like using section headers like this
Copy code
# --------------------------------------
# My section header
# --------------------------------------
b
I lean more into "test behavior not files" camp. And therefore I'm of the "use a tests directory" flavor. In that case, you can have a file per behavior, and that seems to split things nicely 🙂
👍 1
c
I know noisy isn't an objective thing, but I'm having trouble seeing how
Copy code
# --------------------------------------
# Testing Class Foo Method bar
# --------------------------------------

def test_Foo_bar_happy_path():
    pass

def test_Foo_bar_corner_case():
    pass

def test_Foo_bar_corner_zero():
    pass
looks better than
Copy code
class TestFooBar():
    def test_happy_path(self):
        pass

    def test_corner_case(self):
        pass

    def test_zero(self):
        pass
What is the argument for not using classes for tests that doesn't generalize to the 4145 classes under test?
h
I personally don't like extra indentation and having to type
self
with classes hah. But weight my opinion incredibly lowly - I don't actively contribute anymore. I only wanted to offer an alternative if it wasn't considered yet
b
I think instead of classes to group long files, splitting those into multiple files is probably better; in addition to offering some visual separation and grouping like classes, multiple files also allow for greater parallelism when running the tests (a benefit that classes do not offer). I find myself splitting long test files into multiple files within my own work repos and found that to speed up test times significantly.
p
At first, I voted “disagree”, but I changed to “aggree” as I can see cases where a class does make things clearer. Test code is often far more convoluted and difficult to follow than the code under test. Anything we can do to make a particular set of tests easier to grok is a good thing. I think where to use it depends on what you’re testing and your use of fixtures and parametrization. So, I think the style guide should allow it without giving preference to plain classes vs functions. That said, UnitTest classes (which this poll is not talking about) should continue to be prohibited. UnitTest hampers test clarity in all cases (imo).
1
There are cases where a class-scoped pytest fixture can be helpful, though I haven’t done that in the pants codebase. https://docs.pytest.org/en/6.2.x/fixture.html#fixture-scopes So, with that in mind, I increased from “agree” to “strongly agree”.
c
Oh, this was a close one. we're at 50/50, but slightly towards agree due to some being in strong agreements. I didn't expect it to be such a close call that needed a longer voting period 😅 @broad-processor-92400 (and anyone else) do you want to add your vote in the comments? (unless you voted already, I see one as "+1 more" only.. 😛 )
b
TBD nobody strongly disagreed. In some sense, I say let people do what makes them feel better testing, as in general, there's not enough testing
👍 5
b
I'm strongly neutral. Josh's point is a good one 🙂
👍 1
c
I'll sum this up as the majority holds that we may write tests using pytest support for plain test classes. I'll proceed with updating the style guide regarding tests.