Android Unit Test

After Android Studio 2.0 created an empty Android Moudle,

There will be two test directories, one of which is instrument test,

The other is the unit Test

The difference between Unit test and instrument test:

The instrument Test given in Android Developer is explained as follows:

Instrumented unit tests is unit tests that run in physical devices and emulators, instead of the Java Virtual machine (JVM) on your local machine. Should create instrumented unit tests if your tests need access to instrumentation information (such as the target app ' s Context) or if they require the real implementation of an Android framework component (such as a parcelable or SHAREDPR Eferences object). Using instrumented unit tests also helps to reduce the effort required to write and maintain mock code. You is still free to use a mocking the framework, if you choose, to simulate any dependency relationships. Instrumented unit tests can take advantage of the Android framework APIs and supporting APIs, such as the Android testing Support Library.

Simple translation: The instrumented Unit test is allowed on a real machine or emulator, rather than in a virtual machine running on a local environment. If you need to use instrumentation information (such as app Context) while testing, or you need to get the Android framework's components (such as sharedprederences), you can create a Instrumented unit Test. Using instrumented unit test can help reduce the code that writes the simulation environment. Of course you can also use some mock frames. Using the instrumented unit test makes good use of the Android Framework API and the supporting API.

The Local unit Tests (unit Test) given in Android Developer is explained as follows:

If your unit test have no dependencies or only have simple dependencies on Android, you should run your test on a local deve Lopment Machine. This testing approach was efficient because it helps you avoid the overhead of loading the target app and unit test code on To a physical device or emulator every time your test is run. Consequently, the execution time for running your unit test is greatly reduced. With this approach, you normally use a mocking the framework, like Mockito, to fulfill any dependency relationships.

Simple translation: If your unit tests do not depend on the Android environment, then you need to use a local unit test to run on the local JVM, which will help your test speed, because loading the physical device is very time consuming. You can use a Java test framework similar to Mockito.

A simple summary is that these conditions are suitable for use with the instrumented unit test:

• Testing requires Android API support
• You need to use the components in Android when testing
• Testing requires access to specific environment elements in Android (for example, context)

In other cases it is preferable to use Unit Test because it is much faster and more efficient. Second, the instrumented unit test is based on unit test.

Unit Test Environment Configuration:

dependencies {

Testcompile ' junit:junit:4.12 '

Testcompile "org.mockito:mockito-core:1.9.5"

}

Write the test code:

Configuration run:

Operation Result:

Tip: Need to add @Test annotations before testing the method

Two points of knowledge learning:

About the use of annotations in Junit 4:

• @Before This annotated method blocks @Test annotation method, executes before @Test annotation method, and executes in random order if there are multiple @Before methods. The method of this annotation is mainly used to perform some test settings.
• @After the method that is marked by this annotation is executed after all @Test methods, primarily to release the operation of the resource
• @Test the method that is marked by this annotation is your test method, a unit test class can have multiple test methods.
• @Test (timeout=) a @Test annotation label with parameters that returns failure if the method did not complete successfully within the parameter time.
• @BeforeClass the method labeled by this tag will be called the first time the class is loaded, so you can execute a static method in it, such as some static methods that are resource-consuming, such as JDBC operations.
• @AfterClass corresponds to the @BeforeClass, you can release resources after some static operations.

Use of the Assert series method:
Junit provides a series of Assert overloading methods that provide you with a comparison of the expected results (types such as object,long,arrays) and actual results. There is also a assertthat () method that provides the output of a failed Message

Instrumented Unit Environment Configuration:

{
{
"Android.support.test.runner.AndroidJUnitRunner"
}
}

Dependencies{
Androidtestcompile' com.android.support:support-annotations:23.0.1 '
Androidtestcompile ' com.android.support.test:runner:0.4.1 '  
     Androidtestcompile span class= "str" > ' com.android.support.test:rules:0.4.1 '  
     // Optional--Hamcrest library 
     androidtestcompile  ' org.hamcrest: hamcrest-library:1.3 '  
     //Optional--UI testing with espresso< Span class= "PLN" > 
     androidtestcompile  Com.android.support.test.espresso: espresso-core:2.2.1 '  
     //Optional--ui testing with UI automator< Span class= "PLN" > 
     androidtestcompile  Com.android.support.test.uiautomator: uiautomator-v18:2.1.1 '  
 }       

Run Configuration:



Operation Result:

Official Links:

http://developer.android.com/training/testing/unit-testing / Instrumented-unit-tests.html#setup

Demo Address:

Https://github.com/googlesamples/android-testing/tree/master/unit/BasicUnitAndroidTest

Android Unit Test