[GithubBrowserSample] DataBindingIdlingResource doesn't handle nested bindings

[lwasyl]

The DataBindingIdlingResource class is supposed to allow Espresso wait for the bindings to execute before proceeding with the tests. However, current implementation only handles top-level bindings of fragments (and, internally by data binding, child bindings referenced in those). However it doesn't seem to work for example for bindings that are part of the RecyclerView lists, since these views aren't direct views of fragments.

Modified implementation of method that finds bindings that works for me: I decided it's also not really required to look for all the fragments, rather entire view hierarchy. Or am I missing something?

/**
 * Find all bindings for views in the hierarchy
 */
private fun getBindings(): List<ViewDataBinding> {
    return activityTestRule.activity
        ?.findViewById<View>(android.R.id.content)
        ?.allChildren()
        ?.mapNotNull { view -> DataBindingUtil.getBinding<ViewDataBinding>(view) }
        .orEmpty()
}

private fun View.allChildren(): List<View> =
    if (this is ViewGroup) {
        listOf(this) + children.map { it.allChildren() }.flatten()
    } else {
        listOf(this)
    }

I'd issue a pull request with this but, but since I'd need to also modify the tests, which assume fragments (with only one view) I'd rather first open an issue to confirm this would be the proper approach.

I think even if it's not a problem in the sample, this solution is referenced e.g. here so it's worth making it robust for people who will copy it to their own projects.

[JoseAlcerreca]

We are looking for a generic solution for this or perhaps a way to automatically add bindings to Espresso as IRs.

In the testing codelab we use a version that looks at the fragment's children, but not the whole hierarchy either.

[lwasyl]

We are looking for a generic solution for this or perhaps a way to automatically add bindings to Espresso as IRs.

That would be nice. I suppose there's no ETA?

Other than that I'm curious, is there any advantage to inspecting fragments vs activity's content view, like I did? Seems like the sample in this repo missed child fragments case, and in any case both miss recycler items or bindings dynamically added to the views. Or maybe there's yet another case that I should keep in mind?

[JoseAlcerreca]

All updates will appear here android/android-test#317

That's a question for @yigit or @ianhanniballake.

[ianhanniballake]

I've updated our DataBindingIdlingResource to take into account all bindings from the Fragment's entire view hierarchy.