-
Notifications
You must be signed in to change notification settings - Fork 709
Pytest Style: topology/test_crd.py #1527
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
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