-
Notifications
You must be signed in to change notification settings - Fork 1
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
tests fail at midnight? #47
Comments
This is now fixed by adding more night-time realtimeArrival values to the mock-hsl-api. |
The testing failures seems to be still there when actually running tests after midnight. Couldn't get the same failures simulated at daytime. I will try to find out the reason for this. |
Test errors disappeared at 2.00am EET. Seems to be some kind of datetime issue. After 2.00am test_services.py tests are ok again but test_stop.py has one failure:
This one should be solved quite easily by adding more proper nighttime data to the mock-hsl-api and I don't think it's related to the main issue here. edit: Well, actually it looks like the "test_unicode_destination_name"-test fails because it's not using any mocked api data. So basically this test will work again at around 5am EET when the real life traffic starts. If the only function of this test is to test the functionality of unicode in response message, the easiest solution would be testing the suitable stop_name instead of the destination_name. |
Unfortunately, the unicode problem was not visible in |
The issue with ‘test_unicode_destination_name’ is now solved in branch ‘fixing_nighttime_issues’ (also merged to master now) by using freeze_time from FreezeGun library. Freeze_time could also be useful for some other time sensitive tests now and in the future. The issue with test errors in original post seems to exists because a local hsl-mock-api docker container uses UTC time instead of the user’s local timezone time. I have successfully solved this either by running mock-hsl-api locally without a docker (e.g. in PyCharm) or by adding “-v /etc/localtime:/etc/localtime:ro” and “-v /etc/timezone:/etc/timezone:ro” to ‘docker run’ command in command line. There is also an option to add these two volumes to a Dockerfile or to a Docker Compose configure file but I have opted not to do that at this point because I don't have enough knowledge on possible issues with that. However, in my experience, the timezone issue is not there when pushing a branch to a remote branch with Travis CI. So my understanding is that the docker timezone issue is only potential problem in local testing environment. My solution for adding volumes to a 'docker run' command is inspired on this: https://hub.docker.com/r/zinvoice/elasticsearch/. There are also some other suggestions to solve this problem: |
FreezeGun looks really useful for the tests! Regarding timezones, could stop2.0-backend always use UTC time? Or if you need the local timezone, could you always use the "Europe/Finland" timezone definition? This is what we do in the Digitransit backend for Java: https://github.com/HSLdevcom/OpenTripPlanner/blob/master/run.sh#L36 |
(I have to add that any solution including yours is just fine at this point, though!) |
Time is 00:23 and the tests fail in master (commit id 5c3e0d2) although they didn't earlier:
The text was updated successfully, but these errors were encountered: