Make Localization.relativeTime testable#5358
Conversation
Problem is global state in static variable prettyTime. But for performance reasons on Android that is preferred. Now allow injecting prettyTime dependency by making init function public.
|
|
||
| val actual = Localization.relativeTime(GregorianCalendar(2021, 1, 6)) | ||
|
|
||
| assertEquals("1 month from now", actual) |
There was a problem hiding this comment.
Maybe I am just unable to understand Kotlin, in this case please enlighten me. But this assertion will never be true because both times are just 5 days apart from each other - especially when I compare it with the last test? So shouldn't it be assertEquals("5 days from now", actual) here as well?
There was a problem hiding this comment.
You are absolutly correct, but this is actually what pretty time returns. I would guess it's either a bug in PrettyTime or a limitation when comparing with GregorianCalendar.
For these tests i went with the assumption that the current state is correct. So i just added assertions with what is returned, so future regressions are covered.
There was a problem hiding this comment.
okay, can you add this explanation as an inline comment so that no one stumbles upon this later?
There was a problem hiding this comment.
Do you mean the first paragraph of the second (or both)?
I would add the first with the note that further research is required
There was a problem hiding this comment.
just add anything meaningful like // yes this assertion is true, even if it should be 5 days, it works as it is. Future research required
Maybe it has to do something with timezone shift. Could it be that Locale.ENGLISH is defaulting to the global standard locale US in Android? This would explain why 2021, 1, 1 is in fact 2020,12,12 normalized to UTC and could explain "1 month from now"
|
sigh did just see #5230 mayb we should have merged this earlier |
…e_prettytime Make Localization.relativeTime testable
What is it?
Description of the changes in your PR
Context
prettyTime. But for performance reasons on Android that is preferred.relativeTimewould then create a manager object, createprettyTime, determine the app language, etc. https://developer.android.com/training/articles/perf-tips#ObjectCreationprettyTimefor tests while only adding a method call when initializingprettyTimeand otherwise keeping the performance forelativeTimeAPK testing
https://github.com/TeamNewPipe/NewPipe/actions/runs/466273618
Due diligence