-
Notifications
You must be signed in to change notification settings - Fork 101
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
Test of date range in license file #121
Labels
difficulty: unknown or n/a
fix is unknown in difficulty
status: waiting for feedback
waiting for feedback from the submitter
type: question
question directed at the library
Comments
thinkingserious
added
type: question
question directed at the library
difficulty: unknown or n/a
fix is unknown in difficulty
status: waiting for feedback
waiting for feedback from the submitter
labels
Feb 11, 2019
Hello @frenzymadness, How about if we made that unit test throw a warning instead? With Best Regards, Elmer |
That's a good idea. We can write the test this way: def test__daterange(self):
try:
self.assertIn(self.pattern, self.licensefile)
except AssertionError:
warnings.warn("License file does not contain a current year!") which will produce this output in tox and doesn't mark tests as failed.
Does it look good to you? |
Nice! Thanks @frenzymadness! Would you like to submit a PR? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
difficulty: unknown or n/a
fix is unknown in difficulty
status: waiting for feedback
waiting for feedback from the submitter
type: question
question directed at the library
I would like to discuss whether is a good idea to have a test which is testing date range (
Copyright (c) 2012 - 2019 SendGrid, Inc.
). I understand the need described in the original issue (#57) but I don't think that it's a good idea to have a unit test for that.HTTP client is packaged in various Linux distributions. Now imagine that you have packaged HTTP client version from 2018 and you want just a rebuild that package in 2019. It'll fail.
Also, when you create a first pull request after a new year with some bugfix or a new feature, the tests will fail and it's not your fault.
Some workaround might be to change the date range in license file as a first thing every year but you probably don't want to release a new version and without a new version, nobody will update until they have to.
There is a PR to fix the problem now (#120) but I'd rather remove that test entirely. If it's really necessary to test it, it might be possible to move it to Travis config so it'd tested only in CI and not with unit tests.
What do you think?
The text was updated successfully, but these errors were encountered: