Skip to content

Hypothesis tests on convertyear#674

Merged
pganssle merged 6 commits into
dateutil:masterfrom
coreygirard:coreygirard
Apr 15, 2018
Merged

Hypothesis tests on convertyear#674
pganssle merged 6 commits into
dateutil:masterfrom
coreygirard:coreygirard

Conversation

@coreygirard

Copy link
Copy Markdown
Contributor

Added property-based tests to convertyear in dateutil/parser/_parser.py

Refactored convertyear

Comment thread dateutil/parser/_parser.py Outdated
from .. import relativedelta
from .. import tz
#from .. import relativedelta
#from .. import tz

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please don't leave commented-out code

Comment thread dateutil/parser/_parser.py Outdated
'''
Converts two-digit years to year within [-50, 49]
range of self._year (current local time)
'''

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

""" instead of '''

Comment thread dateutil/parser/_parser.py Outdated




Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't add these new whitespace lines. pep8 convention is 1 blank line between methods.

Comment thread dateutil/parser/_parser.py Outdated
if year - self._year >= 50: # if too far in future
year -= 100
elif year - self._year < -50: # if too far in past
year += 100

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like the main difference from the old version is in the case with year - self.year == -50. Is that intentional? (possibly clarified in the tests, which I haven't read yet)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that's intentional. Spoke to Paul about the intended behavior, after testing with Hypothesis found some edge cases. Should otherwise be identical behavior as previous version, with the exception of asserting non-negative input.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jbrockmendel Yeah, so that someone can see my reasoning here, for the boundary of years exactly 50 years ago I think the "tie" should go to the past, not the future, since it's much more likely that you'll be parsing a specific date 50 years in the past than 50 years in the future.

Comment thread dateutil/parser/_parser.py Outdated
# assume current century to start
year += self._century

if year - self._year >= 50: # if too far in future

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pep8 two spaces before an inline comment

Comment thread dateutil/test/test_parser.py Outdated
p = _parser.parserinfo()
new_year = p._year + n
result = p.convertyear(new_year % 100, century_specified=False)
self.assertEqual(result, new_year)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pganssle is there a preferred convention for how to do these assertions? I tend to prefer just assert result == new_year

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jbrockmendel Yeah, these should be refactored as pytest tests. This was part of a sprint event and I told @coreygirard that it was fine to write them as UnitTest tests and I'll refactor them into pytest tests before merging.

Comment thread dateutil/test/test_parser.py Outdated
@given(integers(max_value=-1))
def test_assert_non_negative(self, n):
with self.assertRaises(AssertionError):
_parser.parserinfo().convertyear(n)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

_parser is a private module and should not be directly tested. Only test the public interface, so dateutil.parser.parserinfo.

@pganssle pganssle added the tests label Apr 14, 2018
@pganssle pganssle added this to the Master milestone Apr 14, 2018
coreygirard and others added 5 commits April 15, 2018 12:16
Some reformatting and minor refactoring

Co-Authored-By: Lauren Oldja <[email protected]>
Added assertion that year is always positive.

Co-authored-by: Lauren Oldja <[email protected]>
Co-authored-by: Lauren Oldja <[email protected]>
@pganssle

Copy link
Copy Markdown
Member

I've moved the hypothesis tests into their own separate property testing folder, though it's possible we could do this with marks instead, I'm not entirely sure what the best arrangement is.

I also reverted the way that convertyear was refactored. I don't like that it has multiple return statements in the same function when this can easily be avoided.

@pganssle
pganssle merged commit b7db231 into dateutil:master Apr 15, 2018
@pganssle pganssle mentioned this pull request May 9, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants