What are the difficult steps for Android to perform unit tests? android unit tests

What are the difficult steps for Android to perform unit tests? android unit tests

• Original article: Against Android Unit Tests
• Author: Matthew Dupree
• Source: Development Technology Front Line www.devtf.cn
• Translator: chaossss
• Proofreader: Rocko
• Status: complete

In fact, not only do ordinary Android development engineers find it annoying to test Android applications, but they have been plagued for a long time. For example, Jacob Wharton once made it clear that the Android platform has been developing like an application test since its birth. Don Felker and Kaushik Gopal also put forward the same point of view in their blog. Of course, they also mentioned Google's IOSched application, which has never been tested at all. It is said that IOSched is the best collection of application development in the Android development environment. IOSched has not been tested, which has plagued our developers: 1. Did Google say that "testing is a key link in efficient Android development; 2. Do Google engineers think testing Android applications is a waste of time? In any case, if the best Android development engineers in the world think that testing in Android is very troublesome, it is also a matter of course that we are not good at testing.

For many years, Android Developers have racked their brains to overcome the difficulty of testing in Android. Roboletric is the brainchild of these engineers. It allows developers to perform Android testing on JVM virtual machines. Recently, another blog post began to discuss Fragment, and the leader Chu Square said: Lao Tzu no longer needs Fragment such spam, we need to transform the business logic to the newly developed Mortar & Flow (MVP Development Framework) framework, and use Java-only objects for programming, completely independent of the Android platform API. Without a doubt, it is very simple to test these Java objects in standard Java testing tools.

I firmly believe that the development teams that are on the United Front with Square are also trying to strip the UI from the actual business logic into pure Java objects, make unremitting efforts to improve the testability of applications. In other words, I think we can not perform unit tests in Android, nor implement test units that depend on Android SDK. What we should do is to refactor the application so that we can implement Java-only test units for the code in the application, whether or not we can truly improve the testability and robustness of Android, I think it is worth a try.

I feel that this idea will be a cure, so what we need to do is to use the Android Application Architecture

The result is as follows:

Although this method may fundamentally solve the problem, it also has great risks. Even so, I insist that this method is worth a try, because it can save thousands of developers struggling to implement Android testing units, and do not have to force them to use third-party libraries, after all, the third library will always lag them behind the latest Android system features. In addition, Kent Beck believes that code with good testability is code with excellent architecture. If his opinion is correct, we may find a better way to apply the architecture.

In the next blog, I will explore the operability of the solution "refactoring Android applications so that they can be easily tested using standard Java Tools.

In the first and second blog posts, I will focus on why unit testing in Android brings such a painful experience. I think the root cause that hinders the development of Android testing methods is that the Android system itself is difficult to test. The lack of rational injection of Activity and Fragment is the root cause of making the application hard to test. It is also recognized that this is the key to designing a tested application architecture.

In the third blog, I will discuss a common policy for decoupling application code and Android SDK in details. Simply put, this policy is to hand over the specific behavior of all applications to a POJO Object (Plain Ordinary Java Object) to complete. These POJO objects are specific Android implementations of Android-independent interfaces.

In the fourth blog, I will point out the technical difficulties in implementing the strategies proposed in the second blog, and try to find ways to solve these difficulties. Among these difficulties, the biggest problem lies in Memory leakage and complex code reuse.

In the last blog, I will show you how the architecture I proposed has improved the Android testing performance, so that you can feel that it is worth time and effort to explore such a technology, and get the corresponding return.