RedJocker
commented
2 years ago Keep this one open at least until after reports. We still have to see how users solutions will behave and if this issue is going to cause troubles although currently it looks like it doesn't
Currently we are syncing computer time with robolectric emulated time on the setup, but it gets off again for two reasons actually.
The most significant is when we advance the clock on emulated time, but also emulated time only advances when we advance it so the passing time on computer time against stopped clock on emulated time also produces shifts.
Currently on our test cases it is not a problem. The computer passing time won't be significant enough to be a problem for us. Calling idleFor could become a problem if after a significant amount o shifting we did the time picking routine again. The reason this could be problematic is that solution could call a time api method based on computer time and be out of sync with tests time expectations.
For now I don't think we should do anything, but depending on what you intend to do on next stages this could be a problem if you are not aware of this limitation or also depending on the requirement.
Time has been already a headache on other projects as well and I have wrote a document about it on the documents folder
https://github.com/hatepoint/phrases-hyperskill-tests/blob/main/documents/TimeSensitiveProjectsInfo.md
Maybe you might be interested in reading it. You will notice that so far we have handled each case differently, and we are doing a new one right now with the sync solution.
If this new solution becomes a problem maybe requiring use to kotlinx.datetime like we did on SecrectDiary project could be used. Kotlin track already has a topic for that library and it is an official jetbrains library.