GTAC 2013: Espresso: Fresh Start to Android UI Testing
Why Stack Overflow recommends it
Stack Overflow users link it when explaining how Espresso handles synchronization and why Thread.sleep in Android UI tests is flaky and unnecessary.
Recommended by 2 people across 2 different months, 2013 to 2015.
What it is
A 16-minute GTAC 2013 talk by Valera Zakharov of Google introducing Espresso, a new Android UI test framework with a small, predictable API. It explains how the framework synchronizes with the UI when it is idle so tests avoid sleeps, waits and polling.
What people said
Recommends Taranfx · 2014-10 · Stack Overflow · on “Android UI testing framework”
First, did you try Robotium [LINK] ? It's easy and works for both native, hybrid apps. I use it very often. Integrates smoothly with Maven, Gradle or Ant to run tests as part of continuous integration. import junit.framework.Assert; public class EditorTest extends ActivityInstrumentationTestCase2<EditorActivity> { private Solo solo; public EditorTest() { super(EditorActivity.class); } public void setUp() throws Exception { solo = new Solo(getInstrumentation(), getActivity()); } public void testPreferenceIsSaved() throws Exception { solo.sendKey(Solo.MENU); solo.clickOnText("More"); solo.clickOnText("Preferences"); solo.clickOnText("Edit File Extensions"); Assert.assertTrue(solo.searchText("r
Recommends mellort · 2015-12 · Stack Overflow · on “Android Espresso IdlingResources and Fragment/Activity Transitions”
Espresso will wait for the main thread to become idle before performing operations. Fragment and Activity transitions happen on the main thread, so you do not need to implement any IdlingResource s. What's happening here is that the transition animation is causing flakiness with Espresso's synchronization of the main thread and testing thread. As mentioned in the Espresso setup instructions [LINK] , you should disable system animations on the device used for testing. In general, Thread.sleep statements are bad practice for testing, and will result in unstable and slow tests. Espresso was designed precisely to address this problem on Android. Checkout Valera Zakharov's explanation of the prob
Cites Marc · 2013-07 · Stack Overflow · on “Android detecting when all threads idle -- unit testing”
How do I know when all threads have completed execution and are idle? I am trying to write unit tests for a Java based Android application. The tests require that a content provider is queried, and that contents are added to a ListView prior to the actual test. What I cannot figure out is how to know when all my operations are completed; specifically that the list view has completed its update when the database changed, and that all database operations have completed. I can throw sleeps into my test cases, but as expected they make things unreliable if the system gets under heavy load; and slow down execution. After watching the GTAC 2013: Espresso: Fresh Start to Android UI Testing - YouTub