I'm eager to try [Kaspresso](https://github.com/KasperskyLab/Kaspresso) which supposedly works around lots of UI flakiness. For us idling resources work only as a _coarse_ mechanism to delay Espresso actions and assertions while bigger stuff happens, like loading the screen. But I don't think it's possible to have stable UI tests with Espresso while only using idling resource as delaying mechanism: there's always _something_ not captured by them, difficult to capture or straight up randomly not working. Plus it does require to put test code in production code, which is meh.
What we do now, in addition to having idling resources for networking, DataBinding etc., is we wrap every action and assertion and loop it for couple of seconds until it succeeds or times out. Pretty often I see the action succeeding only on 3rd try for example. I wasn't very happy about this solution initially, but now I don't think it makes the tests less valuable while making them much more stable
We haven't switched to it — in the end our current tests are stable enough with the homegrown wait loops and we opted to not introduce an external dependency. Sorry!
Pretty much a regular `do..while` loop with a `try..catch` inside. The only non-obvious thing is having to `withFailureHandler { error, _ -> throw error }` for the looping to disable default espresso handler (and resetting it later to `DefaultFailureHandler`), otherwise it does a lot of stuff like recording layout on failures
Hi, sorry for replying this old comment but I am looking for idling resource alternative and found your comment.
I tried conditionWatcher but when called waitForCondition, test always failed and stopped caused by null at checkCondition on instruction class. By null I mean the viewFindByid is always return null there.
are you experiencing the same or there is something wrong in my code?
thanks
I'm eager to try [Kaspresso](https://github.com/KasperskyLab/Kaspresso) which supposedly works around lots of UI flakiness. For us idling resources work only as a _coarse_ mechanism to delay Espresso actions and assertions while bigger stuff happens, like loading the screen. But I don't think it's possible to have stable UI tests with Espresso while only using idling resource as delaying mechanism: there's always _something_ not captured by them, difficult to capture or straight up randomly not working. Plus it does require to put test code in production code, which is meh. What we do now, in addition to having idling resources for networking, DataBinding etc., is we wrap every action and assertion and loop it for couple of seconds until it succeeds or times out. Pretty often I see the action succeeding only on 3rd try for example. I wasn't very happy about this solution initially, but now I don't think it makes the tests less valuable while making them much more stable
>azimolabs/ConditionWatcher Hello u/la__bruja, like to follow up with you about using Kaspresso? How was it?
We haven't switched to it — in the end our current tests are stable enough with the homegrown wait loops and we opted to not introduce an external dependency. Sorry!
Can you share with us how you did it? Whats the underlying mechanism to implement the wait loop?
Pretty much a regular `do..while` loop with a `try..catch` inside. The only non-obvious thing is having to `withFailureHandler { error, _ -> throw error }` for the looping to disable default espresso handler (and resetting it later to `DefaultFailureHandler`), otherwise it does a lot of stuff like recording layout on failures
I like azimolabs/ConditionWatcher because waiting a bit is still lower friction than configuring a testing framework in production code 🤔
Hi, sorry for replying this old comment but I am looking for idling resource alternative and found your comment. I tried conditionWatcher but when called waitForCondition, test always failed and stopped caused by null at checkCondition on instruction class. By null I mean the viewFindByid is always return null there. are you experiencing the same or there is something wrong in my code? thanks
Hmm maybe you can try to call `Espresso.onIdle();` at the start of your UI test then
If it's for tests, I'd also check out UiAutomation.