19

I am running Espresso tests on my Android application. The test is flaky. It can reliable assert that the data-model is updated. My problem is that the ViewMatchers can't match the same value in the View because the ViewDataBinding has not yet updated the Views. (At least most of the time the test runs. )

Is there such a thing as an IdlingResource that becomes idle when the ViewDataBinding has no pending changes on the view?

My work-around is a combination of calling executePendingBindings() and a small Thread.sleep(...)

Rene
  • 4,033
  • 2
  • 24
  • 29
  • `executePendingBindings` should be enough: the binding will be executed immediately when calling that method, and not during the next frame of `Choreographer` – pskink Nov 20 '16 at 11:53
  • That was my initial thought as well. But it turns out the test runs on the AndroidJUnit thread and executePendingBindings must run on the MainThread. Scheduling it on the Main is not fast or blocking enough for a failing assert on the AndroidJUnit thread. – Rene Nov 20 '16 at 15:27
  • Did you find a solution? I am have a similar issue where during espresso tests wrong values are passed to the databinding, but if I add a break point and wait for a moment it will send the correct values, the views will be correctly binded and espresso will find the view – Alexandros Ioannou Dec 15 '16 at 17:01
  • Only a horrible SystemClock.sleep(...) currently – Rene Dec 23 '16 at 07:37
  • I end up with the ever green Thread.sleep(..) as well. I guess data binding team and espresso team needs to work together to solve this using an internal idle generator. – rpattabi Jan 16 '17 at 12:13
  • 1
    This bug report https://code.google.com/p/android/issues/detail?id=220247 mentions about workaround using reflection. But I could not get it to work. Anyone succeeded? – rpattabi Feb 19 '17 at 07:23
  • @rpattabi I've applied the solution in the answer and seen it work. At least in the current (2.2.2) version of Espresso that I am now using. – Rene Mar 24 '17 at 06:48

2 Answers2

25

Espresso does waitForIdle before executing view checks. waitForIdle goes thought IdlingRegistry and waits until every IdlingResource is idle.

LoopingIdlingResource is used in Espresso by default. It waits until looper doesn't have messages in queue, which means that it is idle.

However DataBinding uses different approach to schedule an update, it uses Choreographer.postFrameCallback. So updates are not posted into looper queue and Espresso will not wait for them.

In such cases you should register your own IdlingResource. You can find in googlesamples/android-architecture-components nice sample how to implement custom DataBindingIdlingResource and DataBindingIdlingResourceRule that will sets the idle resource before executing tests.

So you have to copy these classes DataBindingIdlingResourceRule and DataBindingIdlingResource into your tests.

And add the following rule into your test class:

@Rule
@JvmField
val dataBindingIdlingResourceRule = DataBindingIdlingResourceRule(activityRule)
Rostyslav Roshak
  • 3,859
  • 2
  • 35
  • 56
  • I looking for this class for Java file but everywhere has Kotlin file. further this app is make by fragment but my application is make by activity – Amir Mohsenian Feb 12 '19 at 14:18
  • 3
    We're tracking a better solution to this in https://github.com/android/android-test/issues/317 – Jose Alcérreca Apr 30 '19 at 10:12
  • This is now outdated, because the example classes use the now deprecated `ActivityRule` instead of the new `ActivityScenario` – Remc4 Sep 08 '21 at 16:33
6

Edit: This is an old answer. Please use Roshak's

The bug report mentioned using reflection to change ViewDataBinding.USE_CHOREOGRAPHER to false for the tests, so here is the solution I came up with:

public static void setFinalStatic(Field field, Object newValue) throws Exception {
    field.setAccessible(true);

    Field modifiersField;
    try {
        modifiersField = Field.class.getDeclaredField("accessFlags");
    } catch(NoSuchFieldException e) {
        //This is an emulator JVM  ¯\_(ツ)_/¯
        modifiersField = Field.class.getDeclaredField("modifiers");
    }
    modifiersField.setAccessible(true);
    modifiersField.setInt(field, field.getModifiers() & ~Modifier.FINAL);

    field.set(null, newValue);
}

Then, just define an ActivityTestRule for the Activity under test, and override its beforeActivityLaunched(). It is necessary to do this before the activity is launched (as opposed to in a @Before annotation) because ViewDataBinding will initialize a Looper if it doesn't use CHOREOGRAPHER.

@Override
protected void beforeActivityLaunched() {
    super.beforeActivityLaunched();
    //Because we are using data-binding, we avoid using CHOREOGRAPHER
    try {
        ReflectionUtils.setFinalStatic(
           ViewDataBinding.class.getDeclaredField("USE_CHOREOGRAPHER"), false);
    } catch (Exception e) {
        Assert.fail(e.getMessage());
    }
}

This way, you can get rid of that Thread.sleep()

verybadalloc
  • 5,768
  • 2
  • 33
  • 49
  • Doesn't work for me. This fails with NoSuchFieldException for "accessFlags". But I see accessFlags on Field class of Android. Not sure why it fails for me. I ran it on lollipop emulator. – rpattabi Apr 07 '17 at 07:50
  • @rpattabi You could try "modifiers" before "accessFlags" as well, as described [here](https://code.google.com/p/android/issues/detail?id=220247#c4). Let me know if that works. I should have noted that this solution worked when using an actual device, so it would make sense it would fail when running the tests inside an emulator jvm. – verybadalloc Apr 07 '17 at 09:15
  • I wrote the info you provided in the link :--) "modifiers" is for desktop jvm and "accessFlags" is for android jvm. Neither of them work for me. – rpattabi Apr 07 '17 at 10:25
  • I checked it on actual device, no exception, yet not clear if this makes espresso wait for data binding. – rpattabi Apr 07 '17 at 10:37
  • @rpattabi I will modify my answer to include the case of running the test on desktop jvm. – verybadalloc Apr 07 '17 at 10:54
  • "This fails with NoSuchFieldException for "accessFlags". But I see accessFlags on Field class of Android." Same on a Nexus 7 running Android 5.1.1 – Rene Apr 08 '17 at 20:39
  • @Rene Can you mention that on the original AOSP issue: https://code.google.com/p/android/issues/detail?id=220247? They might have an explanation for that – verybadalloc Apr 08 '17 at 20:47