You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Been thinking a lot about this recently because I've seen it in a few projects and I'm struggling to see what it offers over a simple Thread.sleep. The only context I can find is this blog post, which simply states "We could use SystemClock.sleep(60000), but that blocks the testing thread.". This is a strange justification since IdlingResources cause onView and onIdle to block the testing thread and this is wanted and expected behaviour for test code (tests are always run synchronously).
As far as I can tell using this IdlingResource is identical to using a sleep from a thread execution standpoint, but the code is more verbose and harder to understand. This seems to me like a misuse of IdlingResource and a testing anti-pattern, and it seems to be used in many codebases where a sleep would be simpler. Please let me know if there's some other execution property that makes this implementation advantageous.
Thanks.
The text was updated successfully, but these errors were encountered:
I agree with you. I wrote ElapsedTimeIdlingResource mostly as an exercise to understand how idling resources work, and there is no real use case. I wish I can retract it but it's been a few years so I'm not sure what's the best way to deal with it.
Thanks for replying
Definitely tricky with so many people using it, but it's not a big problem
if they've got it working and they're happy.
This is still a common challenge new developers face though, and this repo
comes high in search results, so adding more context here could be helpful.
Just a note in the code or readme to say that using sleep is usually fine
and may be the cleanest solution could save some confusion.
Up to you though, certainly not a major issue. 😎
On Fri, 17 Aug 2018, 18:51 Chiu-Ki Chan, ***@***.***> wrote:
I agree with you. I wrote ElapsedTimeIdlingResource mostly as an exercise
to understand how idling resources work, and there is no real use case. I
wish I can retract it but it's been a few years so I'm not sure what's the
best way to deal with it.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#9 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AL7A1qryL3w-_bJmFQJ3iaM_xsqo4TToks5uRwKEgaJpZM4WB68B>
.
Been thinking a lot about this recently because I've seen it in a few projects and I'm struggling to see what it offers over a simple
Thread.sleep
. The only context I can find is this blog post, which simply states "We could use SystemClock.sleep(60000), but that blocks the testing thread.". This is a strange justification since IdlingResources causeonView
andonIdle
to block the testing thread and this is wanted and expected behaviour for test code (tests are always run synchronously).As far as I can tell using this IdlingResource is identical to using a sleep from a thread execution standpoint, but the code is more verbose and harder to understand. This seems to me like a misuse of IdlingResource and a testing anti-pattern, and it seems to be used in many codebases where a sleep would be simpler. Please let me know if there's some other execution property that makes this implementation advantageous.
Thanks.
The text was updated successfully, but these errors were encountered: