How hard is it for Android to unit test-order

• Original link: against Android Unit Tests
• Original Author: Matthew Dupree
• Development technology Front www.devtf.cn
• Translator: Chaossss
• Reviewer: Rocko
• Status: Complete

It's not just the average Android developer who thinks it's annoying to test Android apps, and Daniel has been plagued by it for a long time. Jake Wharton, for example, once made it clear that the Android platform has been testing potential for applications like fire and fire since its inception. Don Felker and Kaushik Gopal also made the same point in their it. Of course, they also mentioned that Google's iosched application, has not been tested, it is said that Iosched is also the Android development environment in the application development of the best collection. Iosched did not test to make us these developers are very troubled: 1, Google's so-called "testing is a key link in Android development" really not to bluff children, 2, or Google's official engineers think testing Android applications is simply a waste of time? Anyway, if the best Android developers in the world find it troublesome to test on Android, it's a good idea that we can play a bad test on the chicken.

For years, Android developers have struggled to overcome the difficulties of testing in Android. Roboletric is the wisdom of these engineers, which allows developers to test Android on a JVM virtual machine. And recently the blog began to denounce Fragment, the leading Square said: "Lao Tzu no longer Fragment This garbage thing, we want to transform the business logic into the newly developed mortar & Flow (MVP Development Framework) framework, with pure Java object Programming, completely independent of the Android platform API. Undoubtedly, these Java objects are very simple to test in standard Java test tools.

I firmly believe that the development teams that stand on the united front with Square must also be looking for ways to peel the UI from the actual business logic into pure Java objects and make unremitting efforts to improve the testability of the application. In other words, I think we can not do unit testing on Android, or implement a test unit that relies on the Android SDK. What we should do is refactor the application so that we can implement a pure Java test unit for the code in the application, and I think it's worth a try, no matter what the eventual ability to actually improve the testability and robustness of Android.

I feel that this idea will be a cure, so what we're going to do is put this Android application architecture

Into this:

Although this approach may solve the problem fundamentally, but it is also very risky, I still insist that this method is worth a try, because it can save thousands of people struggling to implement Android test unit in the fire and fire, and do not have to force them to use a third-party library, After all, the third library always keeps them behind the latest Android system features. In addition, Kent Beck argues that a well-tested code is an architecture-good code, and if his point is right, maybe we can find a better way to apply the architecture.

In the next blog post, I'll explore the operability of "refactoring Android apps so they can easily be tested with standard Java tools."

In the first and second blog post, I'll focus on why unit testing in Android brings such a painful experience. I think the root cause of the development of the Android test method is that the Android system itself is difficult to test. The lack of proper injection of Activity and Fragment is the root cause of the application's difficult to test, and recognizes that this is the key to designing a strong application architecture that can be tested.

In the third Article blog post, I'll discuss a common decoupling application code and the Android SDK strategy in detail. In short, the strategy is to pass the specific behavior of all the applications to a POJO object (Plain ordinary Java object), which are Android-specific implementations of the Android-agnostic interface.

In the fourth Chapter blog post, I will point out the technical difficulties in implementing the strategy proposed in the second blog post, and try to excavate the methods that can solve these difficulties. Among these difficulties, the biggest problem is memory leaks and cumbersome reuse code.

In the last blog post, I'll show that the architecture I'm proposing to improve Android testing has made it worthwhile for people to think that this kind of technology exploration is worth the time, effort, and rewards.

How hard is it for Android to unit test-order