It's hard to do unit testing on Android-end

• Original link: What I ' VE learned from TRYING to make an ANDROID APP UNIT testable
• Original Author: Matthew Dupree
• Development technology Front www.devtf.cn
• Translator: Chaossss
• Reviewer: mr.simple
• Status: Complete

In the previous blog post, I showed you how to use the Square Dafa architecture for Android apps, and in fact, the Square developed a new Android application architecture intended only to enhance the testability of the application. As I said in my Android unit test, it's hard to do unit testing in Android, which can be time-consuming in most cases, and it might be better to try some artifice or third-party libraries. In order to achieve an efficient and non-dependent test unit for third-party libraries, Square Dafa emerges.

In addition, we have difficulty in unit testing on Android where-part1 and Android are hard to unit test.-PART3 Two blog posts on this issue, and finally successfully through Square Dafa for Android applications to implement the test unit, this article is Square Dafa is evaluated and I will proceed from the following three areas:

1. Implementing an efficient test unit for Android apps does not require removing all compile-time dependencies on the Android SDK. (In fact, it is unrealistic to do so.) ）

2. Join us to redesign Square Dafa so that the use of square Dafa does not need to remove all compile-time dependencies on the Android SDK, and the only problem that can occur when trying to run square Dafa into a project is to implement a whole bunch of template code. Fortunately, many of these template codes can be generated automatically through Android Studio.

3. Dependency Injection does make Square Dafa a good way to apply testable cures.

Removing all compile-time dependencies on the Android SDK is neither necessary nor realistic

The initial desire to complete this series is to enhance the testability of your app by making the Android app stack that way:

Next I will tell you that this idea has been misleading us. To make the application more testable, we also need to take advantage of other features of dependency injection, not just to decouple the business logic code from the Android SDK. The initial reason is that the object's Android dependency can be simulated by something like Mockito, and if we can't fully control the test unit's predictive state through mocktio alone, we can replace those Android dependencies with an interface that has a mock implementation. And that's exactly how we can refactor Sessionrepositorymanager in the-part4 of Android for unit testing.

Removing dependencies is not only unnecessary, it is impractical to decouple it completely from the Android SDK, and the problem is that when you try to accomplish this goal, it's important to look back at what you've done, and you'll obviously feel that it's unnecessary, so I'm just going to briefly state the cause here.

To remove all compile-time dependencies for the Android SDK in the removal app may cause the following issues:

1. Applications must define many methods and classes for this purpose.

2. The added interface is almost the same as an existing Android interface.

3. In some cases, the object needs to be injected, and in some cases the object does not need to be injected, and the class constructor with dependencies becomes bloated.

Although there are some problems with square Dafa, this does not affect the interpretation of square in my previous post, and the features of square are still useful and worth trying. Since the app component classes that are available to us in the Android SDK are not being injected, it's really difficult to do unit testing in Android apps, but with Square Dafa, as long as we hand the business logic to a purely Java object that is being injected, it's easy to get to Android Application for unit testing. Although Square Dafa has reduced the need to remove Android SDK dependencies, Square Dafa is still the Dragon Slayer Blades, which enhances the usability of the application. But I personally want to optimize square Dafa so that square Dafa can ignore this requirement, in other words, I would like to find a way of architecting that does not require us to remove all dependencies on the Android SDK.

Tedious template code is a stumbling block to the application becoming testable

If we optimize square dafa so that it no longer requires us to remove the reliance on the Android SDK, square Dafa looks really number one. Pure Java objects that are entrusted with the business logic will be referenced by the component class, enabling them to access properties and callbacks within all component classes. Therefore, the transfer of business logic to pure Java objects with dependency injection should not exclude objects that have the data to perform their duties.

If this is correct, then the only way to prevent us from using Square Dafa is to implement tedious template code. Fortunately, Android Studio provides us with the refactoring options for transitioning to Square Dafa--the Extract Delegate option. With this option, you can automatically transfer the method and instance variables of a class to a delegate class and have the original class handle the logic by invoking the delegate class, rather than relying on the methods of the class itself.

This video shows us how to make use of the Extract Delegate option onStop () to reconstruct sessiondetailactivity and enable it to perform the necessary operations for unit testing. I have explained to you in the previous blog post why it is necessary to do such a refactoring, and it is clear that manual operations do not cover all situations, and that you need to repeatedly implement the method of separating Activity View and data in the code statement block, so that repetitive and meaningless work is a waste of life. So this option is really useful.

Dependency injection is the essence of Square Dafa

It's hard to-part3 Android for unit testing. The secret lies in: Dependency Injection .

-chris Arriola (@arriolachris) May 15, 2015

Square Dafa solves the problem of unit testing for Android because it allows us to inject real dependency into classes that hold business logic, and I emphasize that square allows us to do real dependency injection because the concept of Dependency Injection Also mentioned in the Dagger library, however, Dagger does not really simplify the code for unit testing of Android apps.

This is because Dagger, as it is introduced, is indeed a Service locator library, so Dagger forces us to implement a module that provides mock dependencies for the objects we want to unit test. To make use of these modules, we also ensure that the object graph built by these mock provider modules is the same as the object graph used by the object we are trying to unit test.

And it's this kind of operation that makes Dagger's dependency injection less straightforward than the real dependency injection in Square Dafa, explaining why Dagger can't simplify unit testing of Android apps to write a blog post, so now the only thing I can do is to point this out first, If we understand Martin Fowler's definition of dependency injection (this post is really worth reading, because he created a new term), you'll find that Dagger is really just a Service locator, and Google's official blog about testing has a post explaining it.

Conclusion

If you want the Android app to be able to do unit testing, then use Square Dafa, of course, and I will support it if there are other solutions. Here is a hint of friendship: I just listed a few ways I know, I did not say that Square Dafa number one no one can rival, in fact, enhance the application of testability should have other ways.

This blog post also heralds the end of the series, and I am grateful for the support of every Android developer who has paid attention to this blog post, thanks to everyone for encouraging, forwarding, and praising me on social media. These positive feedback made me realize the importance of discussing and thinking about testing Android apps, and it was the revelation of this series of posts that led me to decide that I would spend more time in the future researching Android testing knowledge in my blog. I will update the blog every Friday, I hope to learn more about the test of knowledge, and everyone to progress together.

It's hard to do unit testing on Android-end