Some time ago when I was rewriting from unittest to pytest I was trying to get rid of as many test classes as possible, would be super happy to see even less of them :D Would this work? Then we just give them more descriptive names and split them per one type of assert, e.g. something like this:

Some time ago when I was rewriting from unittest to pytest I was trying to get rid of as many test classes as possible, would be super happy to see even less of them :D Would this work? Then we just give them more descriptive names and split them per one type of assert, e.g. something like this:

@nejch Thanks for the review!

I will admit that I disagree with this. I prefer the testclass approach as it contains the test cases for a data-type (in this case) into one class. The benefits for this is that all tests for the data-type should be contained within this test class. If in the future the data-type was moved to a different module it will be relatively easy to move the test class to a different test module.

The downside to me of not using test classes is now tests can be added anywhere in the file and tests that are completely un-related to each other can be interspersed throughout the file.

As far as more descriptive names, That can be done inside the test class without issue.

But I would like to learn more on what benefit is gained by not using test classes. As willing to have my opinions changed 😊

Thanks.

Hehe, not sure I want to have a philosophical debate on test classes vs modules here so I'm fine to also merge this as we have a few others in other places 😄 But from my perspective with pytest, since it doesn't use unittest's setup/teardown, the only benefit of classes is namespacing, and for that I prefer modules, so if there was any moving I'd just put them in a separate file I think.
It's also how I see most pytest projects do it, so it's probably more natural for people who know pytest. We already tend to do test module per resource, since tests are longer and trying to do 1:1 module.py<->test_module.py ratio would result in really long test files sometimes.

IMO it would also be quite a task to switch our functions to methods properly now that our suite has grown:

(.venv) nejc@zbook-fury:~/repos/python-gitlab$ grep -r '^    def test_' tests/ | wc -l36(.venv) nejc@zbook-fury:~/repos/python-gitlab$ grep -r '^def test_' tests/ | wc -l579

I'd still prefer to see 1 type of assert per test to ensure they all run as I suggested above at least in unit tests, e.g. when testing raise after asserting on success, but I think we also have quite a few of these in our tests, so I can collect those for a follow-up later.

@nejch Thanks! I for sure am not suggesting we move everything to classes. Just sometimes I prefer classes.

But if do a module per area of testing, how is the file naming typically done for the test module?

Say have a file:foo.py and inside of it we have two gigantic classes we want to test:HugeClass andGiantClass. How would you name the two test modules? Would there be a directoryfoo with two test files under it? Or two test files at the root test level namedtest_foo_HugeClass.py andtest_foo_GiantClass.py? Something else?

Thanks.

I don't have a hard requirement/guideline for that, but either works for me depending on what gets a reasonable size IMO (just with snake case everywhere) :)

For example, we havemixins.py which is a single file, but we have a wholemixins/ test dir where we have multiple modules testing different aspects of it, and you know exactly what aspect is being tested right away before even having to open the file (assuming they're clearly named).

For the client, we still use the opposite (a few root-level files) approach, but in this particular case that means we get up to almost 1k lines and there's a bit of scrolling to get to a test case.

@nejch Thanks!