appium-espresso-driver icon indicating copy to clipboard operation
appium-espresso-driver copied to clipboard

Disabling animations by default results in unexpected consequence

Open rajdeepv opened this issue 5 years ago • 8 comments

As part of #73 Animations are completely disabled for espresso. This results in some unexpected effects like some images are not loaded (In my case even app logo was missing) We can still have it disabled by default but there should be an option not to do so. I ran my test by reverting #73 and it worked fine

rajdeepv avatar Jan 16 '20 14:01 rajdeepv

I also like the idea to make the setting configurable

mykola-mokhnach avatar Jan 16 '20 18:01 mykola-mokhnach

and enabled by default

mykola-mokhnach avatar Jan 16 '20 18:01 mykola-mokhnach

mm, can espresso work on animation scale enabled environment for now? https://github.com/android/android-test/blob/c71339cce96b8abb71c70fa8ae1b7bc4718ea2df/espresso/core/java/androidx/test/espresso/base/DefaultFailureHandler.java#L114

KazuCocoa avatar Jan 17 '20 01:01 KazuCocoa

I tried with my app keeping animation on, did not face any issues. Maybe there can be other apps with never-ending animations that may not work.

rajdeepv avatar Jan 17 '20 13:01 rajdeepv

Thanks. It's interesting.

In my memory, a long time ago worked with animation, but espresso started to raise an exception (I forgot which version). But the limitation has been relaxed again. Ah... or just an error message (not such exception..)

KazuCocoa avatar Jan 17 '20 14:01 KazuCocoa

@mykola-mokhnach @KazuCocoa I ran the full suite of my app with around 400 tests with animation ON and everything looks good I suggest keeping animation ON by default and utilize(implement) disableWindowAnimation capability to disable them if needed

rajdeepv avatar Jan 20 '20 15:01 rajdeepv

Something else I've noticed that may relate to this is that the animation setting is permanently changed on the test device, it is not restored to whatever setting was configured prior to running the tests. I suggest that the driver restore the previous setting after testing is done, perhaps also controlled by a configurable capability.

nicodn avatar Jan 23 '20 15:01 nicodn

@nicodn There is code that restores it. However, if the test is force killed in the middle, it permanently changes this setting.

rajdeepv avatar Jan 23 '20 15:01 rajdeepv

This issue can be closed now.

pr4bh4sh avatar Mar 23 '23 13:03 pr4bh4sh