Difficult to perform unit tests on Android-final stage: android unit tests

Difficult to perform unit tests on Android-final stage: android unit tests

• Original article: WHAT I 've LEARNED FROM TRYING TO MAKE AN ANDROID APP UNIT TESTABLE
• Author: Matthew Dupree
• Source: Development Technology Front Line www.devtf.cn
• Translator: chaossss
• Proofreader: Mr. Simple
• Status: complete

In the previous blog, I introduced and showed you how to use the Square algorithm-based Android application. In fact, Square's development of a new Android Application Architecture only meant to enhance the app's testability. As mentioned in the sequence where it is difficult for me to perform unit tests on Android, it takes a lot of time to perform unit tests on Android, it may be better to try some tricks or third-party libraries. To achieve efficient test units that do not rely on third-party libraries, the Square algorithm came into being.

In addition, we have studied the problem of which part1 and Android are difficult to perform unit tests on Android-part3, finally, we successfully implemented a test unit for the Android app through the Square method. This article evaluates the Square method and I will perform the following three steps:

Removing all Android SDK compilation dependencies is neither necessary nor practical.

The initial desire to complete this series of blog posts is to enhance app testability by making the Android Application Stack look like this:

Next, I will tell you that this idea has always misled us. To enhance the testability of an application, we also need to use other features of dependency injection, instead of just using it to decouple the business logic code from the Android SDK. The initial reason is that the Android dependency of the object can be simulated by something similar to Mockito, and if we cannot completely control the pre-test status of the test unit through Mocktio separately, we can also replace these Android dependencies with mock-Implemented interfaces. This is exactly the way in which it is difficult to reconstruct SessionRepositoryManager in part4 for unit tests on Android.

Removing dependencies is not only unnecessary, but it is impractical to completely decouple it from the Android SDK. The problem is that when you try to accomplish this goal, you may wish to review the work you have done, you will obviously feel that this is unnecessary, so I just want to briefly state the cause and effect here.

To remove all Android SDK compilation Dependencies from an application, the following problems may occur:

Although there are some problems with the Square method, this does not affect my explanation of Square in my previous blog posts. These features of Square are still practical and worth trying. Because the app component classes provided by the Android SDK for our use are not injected with dependencies, it is really difficult for us to perform unit tests in the Android app, but with the Square method, as long as we hand over the business logic to the pure Java object injected by dependencies, we can easily perform unit tests on Android applications. Although the Square method reduces the need to remove Android SDK dependencies, the Square method is still a treasure-killing tool that enhances app testability. However, I personally want to optimize the Square method so that the Square method can ignore this requirement. In other words, I hope to find an architecture that does not require us to remove all Android SDK dependencies,

Tedious template code is a stumbling block that prevents applications from becoming testable.

If we optimize the Square algorithm so that it no longer requires us to remove the dependency on the Android SDK, the Square method seems to be the best in the world. Java-only objects with business logic will be referenced by application component classes so that they can access the attributes and callbacks in all component classes. Therefore, the business logic should be transferred to the pure Java object for dependency injection, and the objects that have data to perform their own duties should not be excluded.

If this is correct, the only thing that prevents us from using the Square method is to implement tedious template code. Fortunately, Android Studio provides us with the refactoring option to transition to the Square algorithm-the Extract Delegate option. With this option, the class methods and instance variables can be automatically transferred to a delegate class, and the original class can call the delegate class processing logic without relying on the class's own methods.

This video shows us how to usethe Extract Delegate optionReconstructs onStop () of SessionDetailActivity and enables necessary operations for unit testing. I have explained in my previous blog why such a refactoring is necessary. Obviously, manual operations cannot cover all situations, in addition, you need to repeatedly implement the separation of Activity View and data in the Code statement block for this purpose. Such repetitive and meaningless work is a waste of life, so this option is really very practical.

Dependency injection is the essence of the Square algorithm

Which of the following is the secret of part3:Dependency Injection.

-Chris Arriola (@ arriolachris) May 15,201 5

The Square method can solve the unit test problem of Android because it allows us to inject real dependencies into classes that hold business logic. What I want to emphasize is that Square allows us to performRealDependency injection is also mentioned in the Dagger library. However, Dagger cannot really simplify the code for unit testing by Android applications.

This is because Dagger, as it describes, is indeed a Service locating library, which forces us to implement a module to provide mock dependencies for the objects we want to perform unit tests. To take advantage of these modules, we also need to ensure that the object graphs built by these mock provider modules are the same as those used by the objects we are trying to perform unit tests.

This operation makes the dependency injection of Dagger easier than the actual dependency injection in Square method, to explain why Dagger cannot simplify the unit test process for Android applications, you can write a blog post. So now, the only thing I can do is to point out this question first, if we understand Martin Fowler's definition of dependency injection (this blog is indeed worth reading, because he created a new term), we will find that Dagger is indeed just a Service locating library, in addition, Google's official blog post on testing also explains this.

Conclusion

If you want the Android app to perform unit tests, use the Square method. Of course, I will support other solutions. Here is a friendly reminder: I just listed several methods that I know. I didn't say that Square is the world's No. one. In fact, there should be other ways to enhance application testability.

The publication of this blog post also marks the end of this series of blog posts. I am very grateful to every Android developer who follows this series of blog posts for their support, I am grateful to everyone for their encouragement, forwarding, and comments on social media. These positive feedback made me realize the importance of discussing and thinking about testing Android applications. It was the inspiration that this blog Series gave me that I decided: I will spend more time studying Android testing knowledge in my blog in the future. I will update my blog every Friday, hoping to learn more about testing and make progress together with you.