[ZZ] Android UI Automated Testing

Google Testing Blog recently published an Android UI automated testing, I reproduced him over,
Outside the wall address: http://googletesting.blogspot.com/2015/03/android-ui-automated-testing.html

See here: http://testerhome.com/topics/2276

Android UI Automated Testing
by Mona El Mahdy

Overview

This post reviews four strategies for Android UI testing with the goal of creating UI tests that is fast, reliable, and E Asy to Debug.

Before we begin, let's not forget an import rule:whatever can is unit tested should be unit tested. Robolectric and Gradle unit tests support is great examples of unit test frameworks for Android. UI tests, on the other hand, is used to verify this your application returns the correct UI output in response to a seque nCE of user actions on a device. Espresso is a great framework for running UI actions and verifications in the same process. For more details about the Espresso and UI Automator tools, please see:test support libraries.

The Google + team has performed many iterations of UI testing. Below we discuss the lessons learned during each strategy of UI testing. Stay tuned for more posts with more details and code samples.

Strategy 1:using an End-to-end test as a UI test

Let's start with some definitions. A UI test ensures that your application returns the correct UI output in response to a sequence of user actions on a Devic E. An end-to-end (e2e) Test brings up the full system of your apps including all backend servers and client app. E 2E tests would guarantee that data are sent to the client app and that the entire system functions correctly.

Usually, in order to make the application UI functional, you need data from backend servers, so UI tests need to simulate The data is not necessarily the backend servers. In many cases UI tests was confused with e2e tests because e2e was very similar to manual test scenarios. However, debugging and stabilizing e2e tests is very difficult due to many variables like network flakiness, Authenticatio n against real servers, size of your system, etc.

When your use UI is tests as e2e tests, you face the following problems:
*very large and slow tests.
*high flakiness rate due to timeouts and memory issues.
*hard to debug/investigate failures.
*authentication issues (ex:authentication from automated tests is very tricky).

Let's see how these problems can be fixed using the following strategies.

Strategy 2:hermetic UI testing using Fake Servers

In this strategy, avoid network calls and external dependencies, if you need to provide your application with data th At drives the UI. Update your application to communicate to a local server rather than external one, and create a fake local server that pro Vides data to your application. Need a mechanism to generate the data needed by your application. This can is done using the various approaches depending on your system design. One approach is to the record server responses and replay them in your fake server.

Once you had hermetic UI tests talking to a local fake server and you should also had server hermetic tests. This is your split your e2e test into a server side test, a client side test, and an integration test to verify the S Erver and client is in sync (for more details on integration tests, see the Backend Testing section of blog).

Now, the client test flow looks like:

While this approach drastically reduces the test size and flakiness rate, you still need to maintain a separate fake serve R as well as your test. Debugging is still isn't easy as you have both moving parts:the test and the local server. While test stability is largely improved by this approach, the local server would cause some flakes.

Let's see it could this is improved ...

Strategy 3:dependency injection Design for Apps.

To remove the additional dependency of a fake server running on Android, you should use dependency injection in your appli Cation for swapping real module implementations with fake ones. One example is Dagger, or you can create your own dependency injection mechanism if needed.

This would improve the testability of your app for both unit testing and UI testing, providing your tests with the ability to mock dependencies. In instrumentation testing, the test apk and the app under test is loaded in the same process, so the test code has Runti Me access to the app code. Not only so, but can also use Classpath override (the fact that test classpath takes priority over app under test) t o Override a certain class and inject test fakes there. For example, to make your test hermetic, your apps should support injection of the networking implementation. During testing, the test injects a fake networking implementation to your apps, and this fake implementation would provide s eeded data instead of communicating with backend servers.

Strategy 4:building Apps into Smaller Libraries

If you want to scale your app into many modules and views, and plan to add more features while maintaining stable and fast Builds/tests, then you should the build your app into small components/libraries. Each library should has its own UI resources and user dependency management. This strategy isn't only enables mocking dependencies of your libraries for hermetic testing, but also serves as an experime Ntation Platform for various components of your application.

Once you have small to dependency injection support and you can build a test app for each component.

The test apps bring up the actual UI of your libraries, fake data needed, and mock dependencies. Espresso tests would run against these test apps. This enables testing of smaller libraries in isolation.

For example, let's consider building smaller libraries for login and settings of the Your app.

The settings component test now looks like:

Conclusion

UI testing can very challenging for rich apps on Android. Here is some UI testing lessons learned on the Google + team:
1.Don ' t write e2e tests instead of UI tests. Instead Write unit tests and integration tests beside the UI tests.
2.Hermetic tests is the go.
3.Use Dependency Injection while designing your app.
4.Build your application to small libraries/modules, and test each one in isolation. You can and then has a few integration tests to verify integration between are correct.
5.Componentized UI tests has proven to be much faster than e2e and 99%+ stable. Fast and stable tests has proven to drastically improve developer productivity.

[ZZ] Android UI Automated Testing