Android unit testing - several important issues

[[173976]]

Original link: http://www.jianshu.com/p/f5d197a4d83a

Preface

I haven’t written an article for a month. I was planning a National Day trip in September and traveled for 14 days before and after the National Day, so I didn’t have time to write, haha.

Let’s get back to the topic. The previous article “Android Unit Testing - How to Start?” introduced several unit testing frameworks, basic usage of Junit & Mockito, dependency isolation & Mock concepts. This article mainly answers several important questions in unit testing.

In the unit testing discussion WeChat group, many new friends have similar questions. After a few of us veterans answered them again and again (shamelessly counting myself in ^_^), I got a little impatient and waited for other students to answer them... In fact, the questions everyone asked are all about "dependency issues", JVM dependency or Android dependency? What should I do if an error occurs when using native methods? How to solve static methods?

So, the author decided to write an article specifically to explain these issues.

• How to solve Android dependencies?
• Isolating Native Methods
• Resolving internal new objects
• Static methods
• RxJava asynchronous to synchronous

1. How to solve Android dependencies?

Xiaobai: "TextUtils is used in Presenter, but when running junit, an error message appears saying 'java.lang.RuntimeException: Method isEmpty in android.text.TextUtils not mocked'... Should I use robolectric?"

Don't worry, it's not time for robolectric to appear yet!

Since junit runs on jvm, and jdk does not have android source code, classes such as TextUtils in android sdk cannot be referenced when running junit. Since jdk does not have it, we can add it ourselves!

In the test/java directory, create the android.text.TextUtils class

 package android.text; 
 
 public class TextUtils { 
 
 public   static boolean isEmpty(CharSequence str) {
        if (str == null || str.equals( "" )) {
 return   true ;
 }
 return   false ;
 }
 }

The key is to create a TextUtils with the same package name, class name, and method name. Note that it is not created under main/java, otherwise it will prompt Duplicate class found in the file... The unit test runs properly:

The principle is very simple. When the jvm is running, it will look for the android.text.TextUtils class, and then find the isEmpty method to execute. Students who have learned java reflection know that as long as you know the package name and class name, you can get the Class. If you know the name of a method in the class, you can get the Method and execute it. The jvm also has a similar mechanism. As long as we give a class with the same package name and class name as the android sdk, and write a method with the same method name, parameters, and return value, the jvm can compile and execute it.

(Hint: Android View and the like can also be done this way)

2. Isolate Native Methods

Xiaobai: "I use native methods, junit fails to run, and robolectric does not support loading so files. What should I do?"

Model class:

 package com.test.unit; 
 
 public class Model {
 public native boolean nativeMethod();
 }

Unit Tests:

 public class ModelTest { 
 
 Model model; 
 
 @Before
 public void setUp() throws Exception {
 model = new Model();
 } 
 
 @Test
 public void testNativeMethod() throws Exception {
        Assert.assertTrue(model.nativeMethod());
 }
 }

run ModelTest... error java.lang.UnsatisfiedLinkError: com.test.unit.Model.nativeMethod()

The "dependency isolation" mentioned in the previous article "Android Unit Testing - How to Start?" is used here!

Improved unit testing:

 public class ModelTest { 
 
 Model model; 
 
 @Before
 public void setUp() throws Exception {
        model = mock(Model.class);
 } 
 
 @Test
 public void testNativeMethod() throws Exception {
 when (model.nativeMethod()).thenReturn( true ); 
 
        Assert.assertTrue(model.nativeMethod());
 }
 }

Run it again and it passes:

Here is a brief introduction to the process of finding native methods in Java:

1). The full name of Model.java is com.test.unit.Model.java;

2). After calling the native method nativeMethod(), the jvm will look for the C++ layer com_test_unit_Model.cpp, then find the com_test_unit_Model_nativeMethod() method and call it.

During the running process of the APP, we will compile the cpp file into a so file, and then let the APP load it into the dalvik virtual machine. But in the unit test, the corresponding so file is not loaded, and the cpp is not compiled! Experts may try to load the so file during unit testing, but it is completely unnecessary and does not conform to the principles of unit testing.

Therefore, we can directly use the Mockito framework to mock native methods. In fact, not only native methods need mocking, but also many dependent methods and classes need mocking. The following will discuss more common scenarios.

(Refer to "Android JNI Principle Analysis")

3. Solve the internal new object

Xiaobai: "I created a new Model in Presenter. Model has many dependencies and can perform SQL operations, etc. Presenter relies on Model to return results, which makes it impossible to unit test Presenter! Please help!"

Example of Xiaobai C: Model:

 public class Model {
 public boolean getBoolean() {
 boolean bo = ....... // A bunch of dependencies, the code is complicated
 return bo;
 }
 }

Presenter:

 public class Presenter { 
 
 Model model; 
 
 public Presenter() {
 model = new Model();
 } 
 
 public boolean getBoolean() {
 return model.getBoolean());
 }
 }

Incorrect unit test:

 public class PresenterTest { 
 
 Presenter presenter; 
 
 @Before
 public void setUp() throws Exception {
        presenter = new Presenter();
 } 
 
 @Test
 public void testGetBoolean() throws Exception {
        Assert.assertTrue(presenter.getBoolean());
 }
 }

Again, dependency isolation. We isolate Model dependencies, that is, mock Model objects instead of new Model().

Let's look at the problem with the PresenterTest above: PresenterTest is completely unaware of the existence of the Model, which means it cannot mock the Model. So, let's find a way to pass the mock Model to the Presenter - pass parameters in the Presenter constructor!

Improved Presenter:

 public class Presenter { 
 
 Model model; 
 
 public Presenter(Model model) {
 this.model = model;
 } 
 
 public boolean getBoolean() {
 return model.getBoolean();
 }
 }

Proper unit testing:

 public class PresenterTest {
 Model model;
 Presenter presenter; 
 
 @Before
 public void setUp() throws Exception {
 model = mock(Model.class); // mock Model object 
 
        presenter = new Presenter(model);
 } 
 
 @Test
 public void testGetBoolean() throws Exception {
 when (model.getBoolean()).thenReturn( true ); 
 
        Assert.assertTrue(presenter.getBoolean());
 }
 }

The problem is solved. If you think it is more convenient to use the default Presenter constructor directly in the Activity and new Model() in the constructor, then keep the default constructor. Of course, when using dagger2, there are no multiple constructors, and all constructors pass parameters.

4. Static Methods

Xiaobai: "Master, I use static methods in Presenter..." Author: "Okay, I know what you mean."

Presenter:

 public class Presenter { 
 
 public String getSignParams( int uid, String name , String token) {
 return SignatureUtils.sign(uid, name , token);
 }
 }

The solution is similar to the above [Solving the problem of internal new objects], and the core idea is still to rely on isolation.

1). Change sign(...) to a non-static method;

2). Use SignatureUtils as a member variable;

3). The construction method passes in SignatureUtils;

4). When unit testing, pass mock SignatureUtils to Presenter.

Improved Presenter:

 public class Presenter {
    SignatureUtils mSignUtils; 
 
 public Presenter(SignatureUtils signatureUtils) {
        this.mSignUtils= signatureUtils;
 } 
 
 public String getSignParams( int uid, String name , String token) {
 return mSignUtils.sign(uid, name , token);
 }
 }

5. RxJava asynchronous to synchronous

Xiaobai: "Great God..."

Author: "I, the master, calculated with my fingers and predicted that you would encounter this disaster."

Xiaobai: (From the beginning to becoming a monk, as the legend goes?)

 public class RxPresenter { 
 
 public void testRxJava(String msg) {
 Observable.just(msg)
                  .subscribeOn(Schedulers.io())
 .delay(1, TimeUnit.SECONDS) // Delay 1 second
 // .observeOn(AndroidSchedulers.mainThread())
                  .subscribe(new Action1<String>() {
                      @Override
 public void call(String msg) {
                          System. out .println(msg);
 }
 });
 }
 }

Unit Testing

 public class RxPresenterTest { 
 
 RxPresenter rxPresenter; 
 
 @Before
 public void setUp() throws Exception {
        rxPresenter = new RxPresenter();
 } 
 
 @Test
 public void testTestRxJava() throws Exception {
        rxPresenter.testRxJava( "test" );
 }
 }

Run RxPresenterTest:

You will find that there is no output "test", why?

Because in testRxJava, Obserable.subscribeOn(Schedulers.io()) switches the thread to the io thread and delays for 1 second, while the testTestRxJava() unit test has already finished running in the current thread. I have tried it, and even if I remove delay(1, TimeUnit.SECONDS), it still does not output 'test'.

You can see that the author commented out .observeOn(AndroidSchedulers.mainThread()). If we add that code and run testTestRxJava() again, we will get java.lang.RuntimeException: Method getMainLooper in android.os.Looper not mocked.:

This is because jdk does not have the android.os.Looper class and related dependencies.

To solve the above two problems, we just need to switch Schedulers.io()&AndroidSchedulers.mainThread() to Schedulers.immediate(). The RxJava development team has thought about it for everyone and provided two hook operation classes, RxJavaHooks and RxAndroidPlugins.

Create RxTools:

 public class RxTools {
 public   static void asyncToSync() {
        Func1<Scheduler, Scheduler> schedulerFunc = new Func1<Scheduler, Scheduler>() {
 @Override
 public Scheduler call(Scheduler scheduler) {
 return Schedulers.immediate();
 }
 }; 
 
        RxAndroidSchedulersHook rxAndroidSchedulersHook = new RxAndroidSchedulersHook() {
 @Override
 public Scheduler getMainThreadScheduler() {
 return Schedulers.immediate();
 }
 }; 
 
 RxJavaHooks.reset();
        RxJavaHooks.setOnIOScheduler(schedulerFunc);
        RxJavaHooks.setOnComputationScheduler(schedulerFunc); 
 
        RxAndroidPlugins.getInstance().reset();
        RxAndroidPlugins.getInstance().registerSchedulersHook(rxAndroidSchedulersHook);
 }
 }

Add RxTools.asyncToSync(); to RxPresenterTest.setUp():

 public class RxPresenterTest {
 RxPresenter rxPresenter; 
 
 @Before
 public void setUp() throws Exception {
        rxPresenter = new RxPresenter(); 
 
        RxTools.asyncToSync();
 }
 ...
 }

Run testTestRxJava() again:

Finally it outputs "test", thank God! (You should give me a reward^_^)

Did you find that RxTools.asyncToSync() has an additional line RxJavaHooks.setOnComputationScheduler(schedulerFunc), which means switching the computation thread to the immediate thread? I found that simply adding RxJavaHooks.setOnIOScheduler(schedulerFunc) still failed for the Obserable with delay, so I switched the computation thread as well, and it worked.

There are also RxJavaHooks.reset() and RxAndroidPlugins.getInstance().reset(). I found that when running a large number of unit tests, some would fail, but running the failed unit tests individually would pass again. After a lot of thinking, I added those two sentences... It works!

(Regarding the use of RxJavaHooks and RxAndroidPlugins, I have mentioned it in the article "(MVP+RxJava+Retrofit) Decoupling+Mockito Unit Testing Experience Sharing" a long time ago)

summary

Author: "Xiaobai, have you filled the hole you stepped on?"

Xiao Bai: "Abbot, no, Master, the above problems have been solved, but there are still some problems."

Author: "How can you fill the hole without digging it? I'll tell you about other unit testing secrets later."

noob:"......"

This article details the solutions to several important unit testing issues. It is not difficult for readers to find that the author has always emphasized dependency isolation, dependency isolation, and dependency isolation. This concept is very important in unit testing. Students who still don't understand this concept can read "Android Unit Testing - How to Get Started?" (another shameless advertisement) several times, and constantly review this concept in practice.

As long as these problems are solved, Presenter unit testing is not difficult. There are also SQLite and SharedPreferences unit tests that are not mentioned in this article, which will be introduced to readers in the following articles.

Thank you readers for your continued support. Please like and forward my article. May good people live in peace and happiness in their lives.

About the Author

I am a keyboard guy. I live in Guangzhou, work in a startup company, and am a sleazy, artistic programmer. I like science, history, investing, and occasionally traveling alone. I hope to become an independent engineer.