Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork64
Test theVersion class#287
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
| from build_docs import Version | ||
| def test_equality() -> None: |
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.
Are all the-> None necessary?
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.
Nope, type annotations are completely optional in Python :)
More seriously, they could be omitted, as we're not running mypy on this repo (yet).
And generally, it is a good idea to also type hints to tests (for example, seehttps://sethmlarson.dev/tests-arent-enough-case-study-after-adding-types-to-urllib3#type-your-tests) and that could cover these returns too.
It can be useful in tests to help immediately differentiate from fixtures and helper methods which do return something, for example in#288.
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.
I was referring specifically to the tests (not fixtures or other helper functions), since they (always?) returnNone, making the-> None superfluous.
I guess it makes sense to add it for consistency, both with other functions/methods that have the return type, or for tests that have types for the their args?
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.
Yeah, we can remove them if you prefer, I don't mind too much either way. But when we add mypy, let's add them back if it complains about it.
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.
Adding them opt-in the function to be checked by mypy, so it will be usefull if we use mypy on this repo sometime.
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
9f45c4e intopython:mainUh oh!
There was an error while loading.Please reload this page.
No description provided.