Espresso RecyclerViewActions.scrollTo issue

[madsbf]

Consider the following code in an Espresso test:

RecyclerViewActions.scrollTo(hasDescendant(withText(someValue)));

The scrollTo-method will go through each item in the adapter one by one and bind to the ViewHolder until it finds a View that fulfills the requirement hasDescendant(withText(someValue)). When the Adapter is a BindingRecyclerViewAdapter, the binding is however never executed, so the scrollTo-method will never work. I looked into this, and found out, that the reason for this, is the following method in the OnRebindCallback:

public boolean onPreBind(ViewDataBinding binding) {
    return recyclerView != null && recyclerView.isComputingLayout();
}

Since we are now trying to bind Views while the RecyclerView is not computing its layout, this method always returns false, and the binding execution is halted.

It shouldn't be too hard for me to make a workaround, that kicks in when running the Espresso tests, but I'm wondering if it would be possible to make a more general approach. Anyway, I will be looking into a solution for this, but wanted to let you and anyone else experiencing this issue know.

[rpattabi]

Anyone successful in making espresso RecyclerViewActions.scrollToXXX() work?

[madsbf]

Yes, I made it work with. I will share a Gist when I get to my laptop.

[madsbf]

https://gist.github.com/madsbf/895228e6e5655c22c4913d49fdd5c545

I use reflection to set mLayoutOrScrollCounter to 1 on the RecyclerView before performing RecyclerViewActions.scrollTo(). Hope this can help you :)

[rpattabi]

@madsbf It works great! Thanks for sharing.

In my case, I needed couple of steps to make it work for me.

1. I am still on binding-collection-adapter v1.3.0, so I changed package import from me.tatarka.bindingcollectionadapter2.BindingRecyclerViewAdapter to me.tatarka.bindingcollectionadapter.BindingRecyclerViewAdapter

2. I had minify enabled even for debug build (forced due to Guava). This stripped out RecyclerView's scrollToPosition which made scrollTo to fail. To prevent this from happening, I had to add the following lines to my debug specific proguard config:

-keep class android.support.v7.widget.** { *; }
-keepclassmembers class android.support.v7.widget.** { *; <fields>; }

proguard probably stripped the code since it didn't catch the use, may be due to reflection.

[evant]

Has anyone reported an issue against the espresso lib for this? Seems like it shouldn't be calling the adapter in a different way than is expected when using in a recyclerview.