android-test icon indicating copy to clipboard operation
android-test copied to clipboard

Behavior difference between Espresso.registerIdlingResources and IdlingRegistry.register

Open jrodbx opened this issue 5 years ago • 1 comments

Description

After this commit: https://github.com/square/RxIdler/commit/643036417fc5f4f4514f60b98b01e7b60064f69a, a behavior change was observed in the Espresso lifecycle, particularly that IdlingRegistry no longer sets registerIdleTransitionCallback. More details here: https://github.com/square/RxIdler/issues/20

Steps to Reproduce

For our use case, we migrated from Espresso 2.2.2 and 3.1.0 and switched from using Espresso.registerIdlingResources to IdlingRegistry.register.

Expected Results

Expected tests to run as normal

Actual Results

Tests crash with a NullPointerException, due to a missing callback. That callback used to be set earlier in the lifecycle via this method: https://github.com/android/android-test/blob/master/espresso/idling_resource/java/androidx/test/espresso/IdlingResource.java#L59

AndroidX Test and Android OS Versions

3.1.0

Link to a public git repo demonstrating the problem:

https://github.com/square/RxIdler/issues/20

A community member has provided a fix which will unblock users, but I would like to confirm whether this lifecycle change is intended behavior or a regression. Put another way: when should a callback be expected to be non-null?

jrodbx avatar May 19 '20 16:05 jrodbx

Experiencing this issue with Espresso 3.5.1. As far as I can see, IdlingResource#registerIdleTransitionCallback isn't called until there has been a call to IdlingResourceRegistry#sync and that won't happen until there BaseLayerModule#provideDynamicNotifer (a Dagger provider) is called.

The problem is that nothing requires provideDynamicNotifer until there's an interaction with the view itself (like an onView with a check or perform) which means that any IdlingResourcethat becomes idle before a view interaction will not yet have aIdlingResource.ResourceCallback. This behaviour does make sense as Espresso doesn't need to care about any idling resources until it's actually doing something, but it doesn't really meet the expectations set up by the [docs](https://developer.android.com/training/testing/espresso/idling-resource) or the JavaDoc on registerIdleTransitionCallback. I think these should be updated so it's clearer that whatever field stores the IdlingResource.ResourceCallbackneeds to be nullable asregisterIdleTransitionCallback` is not called as soon as the resource is registered.

seadowg avatar Nov 17 '23 12:11 seadowg