Pytest Style: topology/test_crd.py #1527
Conversation
I like the approach, but the dealbreaker for me is it is difficult to include extra test methods which are specific to a given format.. This is a pretty typical pattern across parsers and coordinate readers currently: class ParserBase(object):
def test_standard_1():
def test_standard_2():
class TestFormatX(ParserBase):
def test_X_1():
class TestFormatY(ParserBase):
def test_Y_1(): This pattern works well for us as you can have a single file which defines all the testing done for a single format, (eg WRT the multiple arguments that get given to each method, it would be cleaner and easier to define an object (like |
@richardjgowers So then how do we want to proceed? We want to parametrize base classes and then have another class/file for the format specific tests. Or do we want to continue inheriting? |
@richardjgowers do you have more thought about parametrizing of the base classes? |
I recently encountered the use case @richardjgowers described. I would suggest we continue inheriting here. |
@utkbansal inheriting it is then |
@kain88-de @richardjgowers @jbarnoud This is okay? |
Changes made in this Pull Request:
Woah! Pytest is very powerful!
This is branched off another branch so the diff is a bit messy. Here is the actual change I want to show. I parametrized the whole class and it works! I can just delete the
test_crd.py
file!@richardjgowers @kain88-de @jbarnoud @mnmelo The only downside of this is that I have to pass all the parameters to all the methods, but that seems like a tradeoff we can afford. Thoughts?
PR Checklist