4 ms·

Our unit tests break twice a year, starting a couple of days before DST change. I'm sure it could be solved, but since the DST change happens on Sunday and the

by Hamuko 5y ago

Our unit tests break twice a year, starting a couple of days before DST change. I'm sure it could be solved, but since the DST change happens on Sunday and the CI builds fail on Friday, no one has really bothered.

Dunedan 5y ago
So I guess your units tests run with the current date and don't test behavior with different dates. That's something which has the potential to hide quite a few date related bugs until it's too late. What I like to do to avoid this situation is to use property-based testing to test that the code works for all dates in the desired time span. For Python I use hypothesis [1] in combination with freezegun [2] for that. Here is an example of how that could look like: from datetime import datetime, timezone as tz from freezegun import freeze_time from hypothesis import given, strategies as st def business_logic(): # TODO: Refactor before 2038! if datetime.now(tz=tz.utc) > datetime(2038, 1, 19, 3, 14, 7, tzinfo=tz.utc): raise Exception("This code is not working after UNIX time overflow") ... @given(dt=st.datetimes(max_value=datetime(9999, 12, 31, 23, 59, 59), timezones=st.just(tz.utc))) def test_business_logic(dt): with freeze_time(dt): business_logic() test_business_logic() [1]: https://hypothesis.readthedocs.io/en/latest/ https://hypothesis.readthedocs.io/en/latest/ [2]: https://github.com/spulec/freezegun https://github.com/spulec/freezegun
- Hamuko 5y ago
  It's just that the unit tests are built on the assumption that if you go forwards 24/48/72 hours, the time will be the same but N day(s) ahead. And that breaks down when you shift time zones. >don't test behavior with different dates It basically tests with different dates every time it's run.
denton-scratch 5y ago
> the CI builds fail on Friday That seems different from what I understand by "continuous integration".
- patmorgan23 5y ago
  It's just an unintentional read-only Friday

by Hamuko 5y ago

Dunedan 5y ago

So I guess your units tests run with the current date and don't test behavior with different dates. That's something which has the potential to hide quite a few date related bugs until it's too late. What I like to do to avoid this situation is to use property-based testing to test that the code works for all dates in the desired time span. For Python I use hypothesis [1] in combination with freezegun [2] for that. Here is an example of how that could look like: from datetime import datetime, timezone as tz from freezegun import freeze_time from hypothesis import given, strategies as st def business_logic(): # TODO: Refactor before 2038! if datetime.now(tz=tz.utc) > datetime(2038, 1, 19, 3, 14, 7, tzinfo=tz.utc): raise Exception("This code is not working after UNIX time overflow") ... @given(dt=st.datetimes(max_value=datetime(9999, 12, 31, 23, 59, 59), timezones=st.just(tz.utc))) def test_business_logic(dt): with freeze_time(dt): business_logic() test_business_logic() [1]: https://hypothesis.readthedocs.io/en/latest/ https://hypothesis.readthedocs.io/en/latest/ [2]: https://github.com/spulec/freezegun https://github.com/spulec/freezegun

Hamuko 5y ago
It's just that the unit tests are built on the assumption that if you go forwards 24/48/72 hours, the time will be the same but N day(s) ahead. And that breaks down when you shift time zones. >don't test behavior with different dates It basically tests with different dates every time it's run.

denton-scratch 5y ago

> the CI builds fail on Friday That seems different from what I understand by "continuous integration".

patmorgan23 5y ago
It's just an unintentional read-only Friday