Loading...
Home
  • Tech Blogs
  • Videos
  • Conferences
    • Droidcon News
    • Upcoming Conferences
    • Become a Partner
    • Past Events
    • Keep Me Informed
    • Diversity Scholarships
  • Community
    • droidcon Team
    • How to Hold a Droidcon
  • Android Careers
Sign In

Global CSS

 

ProgressBar animations with Espresso

 

 
Halil Ozercan
Opsgenie@Atlassian / Kawaii Android Developer / Ankara
Published: September 30, 2020
Tweet
Share
 

 

It is not uncommon that once you run into an issue with Intrumentation Testing in Android, you’d feel like the loneliest person in the world. This might be an unforeseen effect of abundance of Android knowledge that exists on the Internet. Whatever you search for, there is always a StackOverflow answer or a Medium article that exactly describes what you need to do. However, this doesn’t hold for testing. My assumption is that this trend would hold in many other areas of Software Engineering. Although TDD is being popularized, it is still fairly rare, especially among one-developer teams which is unfortunately very common in mobile teams.

 

Problem: Animations in Espresso

Espresso has quite a bit obsession with idleness. Any action or assertion on views first require everything to settle on UI. In other words, if anything is still moving on your screen, Espresso will happily wait before executing any command. This doesn’t necessarily cause a problem if we are talking about transition or window animations that take fraction of a second. However, what happens if we want to show a ProgressBar or some sort of drawablethat is animated when the screen goes into a loading state.

 

 

Wow, that’s not pretty. Espresso looped around 10k times and finally gave up after a minute. What can we do to circumvent this issue and tell the Espresso that the screen is actually idle?

 

Proposed Solutions

Let’s do a quick Google search and see what we find

  1. Replace the Progressbar right after test starts

 

ProgressBars and Espresso

Asked When I have a ProgressBar in layouts that are displayed when running some espresso-tests - then I run into…

stackoverflow.com

 

There is no accepted answer so we can start with the most upvoted one. It simply suggests that if your Progressbar is invisible at the start of the test(yes, in our case), just change its drawable with something static so it does not animate.

Although this may sound very legit and works, it doesn’t feel right to me. First of all, there is a big assumption that my test will start without showing the progressbar. When this doesn’t hold, the whole approach fails. Secondly, it requires me to mess with UI during testing. Not before, not after, but exactly at the time of running the test. This hack sounds innocent but violates some of the principles of UI testing.

2. Override Progressbar for Debug builds (or for any flavor)

This was the first thing that also I thought of. Create a new ProgressBar, extending from the original ProgressBar, and stop the animation in Debug builds.

I wouldn’t recommend directly doing this because debug builds are intended to be used by developers during hands on testing or development time, in which animations should not be disabled for any reason. Luckily, we have a flavor of our app that is intended for instrumentation testing. Instead of debug builds, we can disable the animations according to this flavor.

 

 

Again like the first one, this approach works if you are OK with it. My concern is that changing production code and adding logic to circumvent a testing issue might cause unpredictable side-affects. Also, it’s again in violation of core principles of UI testing.

3. Others

As far as I checked, all the other solutions are derivatives of the first two that we have discussed. Either intercept during testing and alter the offending drawable, or change production code to account for testing. In some cases, people have given up completely and maybe stopped testing these screens.

 

Testing progress bar on Android with Espresso

The workflow should be the following: Activity starts Progress bar is visible Network request fires (idling resource is…

stackoverflow.com

 

In the above answer, the author suggested the use of UiAutomator. If Espresso can’t handle idleness of a progress drawable, we can simply take the control from Espresso and give it to another library with similar functionality.

 

Another Possibility and Other Animated Drawables

Until now, I haven’t even mentioned my original problem. To our bad luck, the problematical view is not even a ProgressBar or derivative of it. A custom button view that shows a Progress animation when its state switches to Loading . The drawable inside it is private so the first solution is out the window. The second solution is also out-ruled because we don’t want to interfere with production code logic.

Fortunately, there is something missing in Stackoverflow answers. Do you remember a line that 99% exists in your build.gradle file?

 

testInstrumentationRunner "com.example.hello.HelloTestRunner"

 

This custom test runner has incredible capabilities when it comes to meddling with your app during testing. For example you can override every activity’s oncreate . There, you can utilize custom Layout Inflater Factories to your liking.

 

 

Now, we can just swap any view with another stub implementation that simply disables animations during testing.

 

 

This method doesn’t care about your actual implementation. It can be thought of as a TestRule . When your test starts, your activities’ inflater factories are swapped with this class. The view classes that you are not interested in modifying will keep inflating as always but the ones you want to swap out will be changed with the new Stub implementations. In these stub implementations you can disable animations and do whatever you want as long as you are respecting the fundamental rules of instrumentation testing.

 

 

 

Tags: Android, Espresso, Testing, Android App Development, AndroidDev

 

 

View original article at: 


 

Originally published: September 18, 2020

Android News
Compose CameraX on Android
Compose CameraX on Android

By Peng Jiang

Android new UI toolkit Jetpack compose is in beta now, which has all the features you need to build production-ready apps. CameraX is another Jetpack support library, which let you control the camera easier. As compose is still under development, lots of the views are still not available the compose way.

By ProAndroidDev -
Android News
Getting… your BottomSheetScaffold working on Jetpack Compose Beta 03
Getting… your BottomSheetScaffold working on Jetpack Compose Beta 03

By Carlos Mota

It’s Monday, no releases this week, and… there’s a new version of Jetpack Compose — beta 03—available. What a perfect time to just increment 02 to 03 and see what’s new. The API is (almost) final so after updating from alpha to beta there weren’t any big changes to do. However, and remember that’s still in development, there’s always something that I need to update. 

By ProAndroidDev -
Android News
Noisy Code With Kotlin Scopes
Noisy Code With Kotlin Scopes

By Chetan Gupta

Scopes make your code more readable? think again... You are going to encounter these scope functions namely let, run, apply, also, within every Kotlin codebase, along with all the mischievous ways developers exploit their usage from the way they were intended for. Let see how popular opinion on those ends up just as a code noise.

By ProAndroidDev -
Android News
Improving Android DataBinding with Bindables library
Improving Android DataBinding with Bindables library

By Jaewoong Eum

DataBinding is one of the most important factors for MVVM architecture. The basic concept of DataBinding is to link the view and view model via observer patterns, properties, event callbacks, etc. Linking and automating communication between the view via the bound properties or something in the view model has a lot of benefits in the MVVM architecture concept.

By ProAndroidDev -
droidcon News

Tech Showcases,

Developer Resources &

Partners

/portal/rest/jcr/repository/collaboration/Groups/spaces/droidcon_hq/Documents/public/home-details/EmployerBrandingHeader
EmployerBrandingHeader
https://jobs.droidcon.com/
/portal/rest/jcr/repository/collaboration/Groups/spaces/droidcon_hq/Documents/public/employerbranding/jobs-droidcon/jobs.droidcon.com
jobs.droidcon.com

Latest Android Jobs

http://www.kotlinweekly.net/
/portal/rest/jcr/repository/collaboration/Groups/spaces/droidcon_hq/Documents/public/employerbranding/kotlin-weekly/Kotlin Weekly
Kotlin Weekly

Your weekly dose of Kotlin

https://proandroiddev.com/
/portal/rest/jcr/repository/collaboration/Groups/spaces/droidcon_hq/Documents/public/employerbranding/pad/ProAndroidDev
ProAndroidDev

Android Tech Blogs, Case Studies and Step-by-Step Coding

/detail?content-id=/repository/collaboration/Groups/spaces/droidcon_hq/Documents/public/employerbranding/Zalando/Zalando
/portal/rest/jcr/repository/collaboration/Groups/spaces/droidcon_hq/Documents/public/employerbranding/Zalando/Zalando
Zalando

Meet one of Berlin's top employers

/detail?content-id=/repository/collaboration/Groups/spaces/droidcon_hq/Documents/public/employerbranding/Academy for App Success/Academy for App Success
/portal/rest/jcr/repository/collaboration/Groups/spaces/droidcon_hq/Documents/public/employerbranding/Academy for App Success/Academy for App Success
Academy for App Success

Google Play resources tailored for the global droidcon community

Follow us

Team droidcon

Get in touch with us

Write us an Email

 

 

Quicklinks

> Code of Conduct

> Terms and Conditions

> How to hold a conference

> FAQs

> Imprint

Droidcon is a registered trademark of Mobile Seasons GmbH Copyright © 2020. All rights reserved.

powered by Breakpoint One