Thursday, June 2, 2016

Advanced Espresso at #io16

I missed the Advanced Espresso talk at Google I/O this year because it was at the same time as Building rich fitness experiences with Google Fit platform and Android Wear, where Fit Cat was featured.

Finally got a chance to watch it at home, and wow, lots of good tips and tricks!

onTransitionToIdle (at 10:33)

According to the talk, it's preferable to set the state of the idling resource once, and call the idle transition callback when the state changes to idle. A good example is CountingIdlingResource, in the decrement function.

I went back to look at my custom idling resources, and try to skip calling the idle transition callback in isIdleNow. That gives me this error:

Caused by: java.lang.IllegalStateException: Resource com.sqisland.espresso.idling_resource.intent_service.IntentServiceIdlingResource isIdleNow() is returning true, but a message indicating that the resource has transitioned from busy to idle was never sent.

So it's seems like I must call the callback. From the doc, it seems harmless to call it multiple times, so I'm going to leave my querying idling resources as is.

For idling resources that query the state in isIdleNow, there is no need to call the idle transition callback. See IntentServiceIdlingResource for an example.

loopMainThreadForAtLeast (at 11:18)

Try to avoid it, but if you need some time to pass in your test, do not call Thread.sleep or SystemClock.sleep. Instead, use UiController.loopMainThreadForAtLeast.

You will need to make a custom ViewAction to get access to the UiController. Note: Not to store the UIController outside the ViewAction, because it may not be valid any more.

More tips

  • (12:10) Do not copy and paste between tests. Create helper functions.
  • (13:35) Use available Matchers. Write your own only if necessary, with TypeSafeMatcher and BoundedMatcher.
  • (15:08) Use CountingIdlingResource.
  • (15:54) Change IdlingPolicy if the defaults are too short.
  • (16:35) Focus on testing behavior, not layout properties. Use position assertions e.g. isBelow if you must verify layout. They are relative and easier to maintain.
  • (17:35) Write many small tests rather than large ones.
  • (18:44) Launch directly into desired screen and state with intents.
  • (19:56) Most UI tests should be as hermetic as possible.
  • (20:37) Use Espresso Intents to intercept Intents that launch external apps.
  • (21:19) Learn how to run long running animations. Read ANIMATOR_DURATION_SCALE from system settings and disable that in your app when it is zero. Show surface updates from Developer Tools to see hidden animations.
  • (24:00) Implement your own FailureHandler if you want to log extra information when your test fails.
  • (24:41) Developer Tools FTW!
  • (25:05) Change touch and hold delay for slow devices / emulator
  • (25:49) Enable testing for accessibility issues. Super easy: AccessibilityValidator.enable()

Thank you Wojtek KaliciƄski for the informative talk!

No comments:

Inline coding questions will not be answered. Instead, ask on StackOverflow and put the link in the comment.

Post a Comment