Fix #1968: Fix NavigationDrawerTestActivityTest for Robolectric

[anandwana001]

Explanation

Fix #1968

Checklist

• The PR title starts with "Fix #bugnum: ", followed by a short, clear summary of the changes. (If this PR fixes part of an issue, prefix the title with "Fix part of #bugnum: ...".)
• The PR explanation includes the words "Fixes #bugnum: ..." (or "Fixes part of #bugnum" if the PR only partially fixes an issue).
• The PR follows the style guide.
• The PR does not contain any unnecessary auto-generated code from Android Studio.
• The PR is made from a branch that's not called "develop".
• The PR is made from a branch that is up-to-date with "develop".
• The PR's branch is based on "develop" and not on any other branch.
• The PR is assigned to an appropriate reviewer in both the Assignees and the Reviewers sections.

[BenHenning]

So I've been investigating this. When digging into why click() is failing (e.g. due to the 'Admin' text not being at least 90% visible), I found something interesting. The internal check to Espresso uses something called view.getGlobalVisibleRect() to get the visible rect of the child. That function, internally, relies heavily on its parent to determine if it's visible (e.g. by calling ViewGroup.getChildVisibleRect()). If you follow this up to the DrawerLayout starting at the admin text, all views underneath that layout are visible until you reach that point of the hierarchy. The child in question is NavigationView and it has an mLeft value of -768 (meaning the menu is completely offscreen when Robolectric is trying to interact with it).

Not sure why Robolectric isn't waiting for the drawer to open--trying to figure that part out now.

[BenHenning]

I have a decent idea why this is happening now, but don't yet have a workaround. Clicking to open the navigation drawer is piping through ActionBarDrawerToggle & into DrawerLayout.openDrawer() as expected. However, it starts going downhill from there: openDrawer() uses a utility class called ViewDragHelper + an override to computeScroll() to scroll the drawer open after being told to open. The initiation of this process is working, but unsurprisingly Robolectric doesn't call into computeScroll() correctly (we've run into this problem in past tests, too). Looking for a way to force the scrolling.

[BenHenning]

Aha, it seems that computeScroll() is only called during the View's drawing step, and Robolectric skips view rendering. It's a bit bad that Android has a rendering process with side effects imo, but that's something that we need to live with for certain animations it seems.

[BenHenning]

Hmm. Apparently just calling computeScroll() opens the drawer enough to fix the test. I'm not sure why it works with just one call (real Android calls it 3-4 times with an emulator & debugger attached)--maybe it has something to do with the fake time. We may need to tweak this if we see flakes in the future, but it's easily isolatable. Will post fixed version of the test suite soon.

[BenHenning]

Here's my partially working implementation: https://gist.github.com/BenHenning/e0c3c6d729409d74bcb2e213a6557db6/revisions. Some tests are passing, and I think the mechanism being introduced here is correct. Some additional changes that I think will be needed:

1. I don't think we can use open() for the drawer--we should probably use the mechanism I introduced here (which may need to be generalized to support different screens besides home)
2. A lot of these tests are performing multi-activity tests--they need to split apart since Robolectric doesn't support actually changing activities

All of the tests are passing on Espresso, and a bit less than half are passing on Robolectric. The other failures seem mainly tied to testing multiple activities, so I'm deferring to you @anandwana001 to finish up those pieces.

[BenHenning]

(Reassigning since I don't think I have anything left to do here since I found a workaround for the core issue).

[BenHenning]

Ack thanks @anandwana001. Will do a review pass later today my time.

[BenHenning]

Thanks @anandwana001! Overall, this LGTM (and I'm really happy to see all of the disables removed here--these were quite tricky!). Just a few comments before I'll approve.

[BenHenning]

Thanks @anandwana001! Just a few more comments.

[BenHenning]

Thanks @anandwana001! Besides the comment for filing an issue, just had one other comment. Feel free to merge once both comments are addressed.