The library is a unbundled static testing library for Android that containers all Android testing frameworks by Google. It will become a available through the Android Support repository and as open source in AOSP.

So what does it contain?

• AndroidJUnitRunner
  This Runner, based on android.test.InstrumentationTestRunner, runs JUnit3 and JUnit4 tests against an Android package (application). Let me give an example:
  @RunWith (JUnit4.class)
  public class MyJUnit4Test {
  {
    Droidcon mDroidconUK;
   
    @Before
    public void setUp() {
      mDroidconUK = new Droidcons.get(Droidcon.UK);
      mDroidconUK.open();
    }
  
    @Test
    public void checkPreconditions() {
      assertNotNull("mDroidconUK cannot be null", mDroidconUK);
    }
  
    @After
    public void tearDown() {
      mDroidconUK.close();
    }
  }

• Espresso
  Introduced at the GTAC in 2013, Espresso makes it possible to write concise, beautiful, and reliable Android UI tests quickly. Lets look at some examples:
  // Find view using a Matcher and type text using a ViewAction
  onView(withId(R.id.message_edit_text)).perform(typeText(TEXT_MESSAGE), closeSoftKeyboard());
  
  // Perform a click ViewAction
  onView(withId(R.id.send_button)).perform(click());
  
  // Verify using a ViewAssertion
  onView(withId(R.id.received_message_text_view)).check(matches(withText((TEXT_MESSAGE))));

• Intento
  Intento is like Mockito but for Intents. Basically a mock framework that allows you to create and configure mock objects. Let me give you an example:
  public void testDailerInput_typeNumberAndCall() {
   
    //Type phonenumber in dialer
    onView(withId(R.id.send_data_to_call_edit_text)).perform(scrollTo(), typeText("123-345-6789"), closeSoftKeyboard());
   
    // Click the call button
    onView(withId(R.id.send_to_call_button)).perform(scrollTo(), click());
   
    //Validate Intent has been send
    intended(allOf(
        hasAction(Intent.ACTION_CALL),
        toPackage("com.android.phone"),
        hasData(allOf(hasSchemaSpecificPart("tel", "123-345-6789")))),
        times(1));
  }

In conclusion: Testing with Android is finally becoming a more prominent part of Android Development cycle with the introduction of the Android Testing Support Library

“And, is the application still works?” or “Is the application broken?”, these are questions that developers should be able to answer if a code change has been made or an improvement has been added. This is no different when developing an Android application. Also, the use of TDD (Test Driven Development), in which first the test is written, after which the code follows, is good practice. Automated functional testing has become part of software development. Using Selenium and Fitnesse for testing Java application, combined with Jenkins has become avery day pratice to most Java developers. So you would expect that this would differ during the development of Android app. Unfortunately this is not (yet) the case. Because of the relatively rapid growth of Android, these testing methods aren’t yet mature enough.

Lets look at four testing framework that can be used during Android app development:

 
The Android application that is being tested is a simple calculator. The common test scenario we will be implementing is testing if ‘1’ + ‘3’ gives a result of ‘4’.

UIAutomator

The Google test framework UIAutomator makes it possible to write simple Java (and JUnit) functional tests. The framework is not tied to the application that needs to be tested, but also has access to the Android platform itself.
This makes it possible to adjust your Android emulator or physical phone settings while running your test(s). This means that you can test the behavior of the test application if, for example, the internet connection is being switched off.

Unfortunately there is little documentation available. Also the framework only supports Android 4.1 or higher.
In short:

• Fully control device
• Code written in Java
• Extends JUnit framework
• Easy to read
• Only for Android 4.1 and higher
• Little documentation available

Robolectric

The Java-based testing framework Robolectric is the best of the tested frameworks in terms of performance. This is because it is not running on a device or on the Android emulator, but uses his own visual UI simulator. As a result, the delaying factor of starting an emulator or installing the app on a device has no influence on running the test(s). This makes Robolectric a good choice for TDD.

Because Robolectric uses a non-visual UI simulator its not possible to test a problem which only occurs on say a Samsung device.
In short:

• Does not require emulator or device
• Code written in Java
• Extends JUnit framework
• Fastest in terms of performance
• Does not run on actual device

Robotium

The idea behind Robotium is that a functional test should description what the user sees and can do. This framework is a good choice if you are just “black box” testing your application. Besides extensive documentation, there are some well described examples available and the API is easy to use.

In short:

• APIs are easy to use
• Tests are text-based
• Good for “black box” testing

Calabash-Android

Like Robotium, the functional tests described in Calabash Android is written as “What you see you test”. The only difference is that the tests are not written in Java, but in Cucumber (a text-based structure). This makes it possible that tests can be written/used by non developers. A drawback, because test(s) aren’t written in Java, is that “debugging” a failing test is not possible.

In short:

• Well documented
• Test(s) can be writen/used bij non developers
• What you see, you test
• ‘Debuggen’ of tests isn’t possible

Conclusion

Functional testing of Android applications is possible. Which test framework you want to use, dependents on the what you want to do with it. To choice with one fits best, ask yourself who is going to make the tests, what needs to be tested and/or on which device the tests are running on.In any cast, there is enough choice to start writing functional tests.

Source code can be found here