Android basics 12: Android automated testing 06-Instrumentation 05 instrumentationtestrunner

As I learned more about Android and JUnit, I found more and more related content. Sort these classes according to the inheritance relationship as follows:

• Test-testcase-androidtestcase
• Test-testcase-instrumentationtestcase
• Test-testsuite-instrumentationtestsuite
• Testlistener -- basetestrunner-androidtestrunner
• Instrumentation-instrumentationtestrunner

The first four routes are the expansion of Android on the JUnit framework, and the last line is an important line. It is explained in one sentence that this is an icing on the cake for Android on the basis of the JUnit framework. In the study of Android. App. instrumentation, we have a certain understanding of instrumentation. In this article, we will introduce the last class of instrumentationtestrunner. Before learning this class, let's add some knowledge: I learned so much before, but in our test example, I didn't see the core class instrumentationtestsuite (this class is equivalent to the container in the test unit, all testcase needs to be added with testsuite for management). Why? Because in Android
The SDK has a deep "packaging" for this part. It is precisely with this intermediate layer that we did not see the container testsuite. The intermediate layer is introduced below.

Android. Test. suitebuilder

The package name seems to be telling us the role of this package: suite generator. Its package structure is as follows:

We don't seem to see what we want from this figure. Next let's take a closer look at the testsuitebuilder class:

Using the above keywords: exclude (exclude; excluded), include (include, include), the given packages and all sub-package (given package and all sub-packages ), these make us feel that the main role of the testsuitebuilder class is to add or exclude packages in the current unit test. You don't want to get started with the startup commands described in the unit test section:

adb shell am instrument -w com.xmobileapp.hello/android.test.InstrumentationTestRunner

The actual purpose of this command is to add com. xmobileapp. Hello to the current unit test. Here we will list some of the commands as follows:
Run a testcase:

adb shell am instrument -w -e class com.android.foo.FooTest com.android.foo/android.test.InstrumentationTestRunner

Run a function in a testcase:

adb shell am instrument -w -e class com.android.foo.FooTest#testFoo com.android.foo/android.test.InstrumentationTestRunner

Test multiple testcase at the same time:

adb shell am instrument -w -e class com.android.foo.FooTest,com.android.foo.TooTest com.android.foo/android.test.InstrumentationTestRunner

After reading these commands and combining testsuitebuilder functions, I think you will understand an important problem: In androidmanifest. why is there no description related to testsuite In the attributes of the XML file instrumentation (as shown in?

The unit test configuration has replaced testcase management, so the functions of testsuite are much weaker. testsuitebuilder is the configuration of the test scope for the current test, for example: whether to add a testcase to the current test. Function builder of the testsuitebuilder class generates testsuite based on our configuration. We have fewer doubts here. Next we will continue to introduce the instrumentationtestrunner class.

The entationtestrunner class structure is shown in:

The main function interfaces are listed as follows:

Typical use process of instrumentationtestrunner:

1. Write test cases. Test Cases are inherited from the following classes;
   L activityinstrumentationtestcase
   Activityunittestcase
   Androidtestcase
   Applicationtestcase
   Instrumentationtestcase
   Providertestcase
   Servicetestcasesinglelaunchactivitytestcase
2. Define an instrumentation in androidmanifest. xml and specify the name of the tested package in the targetpackage attribute;
3. Run instrumentation and use "ADB shell am instrument-W" to run all tests (except performance tests );
4. Run the instrumentation command "ADB shell am instrument-W" and add the additional command "-e func true" to run all function tests. Thanks for the inheritance of the test to the instruments entationtestcase;
5. Run the instrumentation command "ADB shell am instrument-W" and add the additional command "-E unit true" to run all unit tests. These test classes that are not inherited from instrumentationtestcase;
6. Run the instrumentation command "ADB shell am instrument-W" and add the additional command "-E Class" to run a separate testcase.

After reading the above commands, let's take a look at apidemos \ test \... Some annotations in \ alltests. Java are as follows:

Everyone should understand what these comments mean, and the purpose of this article is achieved.
The following is a brief example:

public class ApiDemosRunner extends InstrumentationTestRunner {@Overridepublic TestSuite getAllTests(){Log.i(“ApiDemosRunner”, “ApiDemosRunner::getAllTests()”);return new TestSuiteBuilder(ApiDemosRunner.class).includeAllPackagesUnderHere().build();}@Overridepublic ClassLoader getLoader(){return ApiDemosRunner.class.getClassLoader();}}

After reading this code, you will understand the main role of testsuitebuilder. here we need to note that testsuite is the core of the test, but testsuitebuilder is added to the android SDK, it is easier for us to manage testcase. The instrumentationtestrunner class is relatively simple. After reading the above example, you can use this method later. This is not detailed here.

Summary

The android SDK is well encapsulated in unit testing. We can complete unit testing without writing too much code.

References:

Analysis of Android. Test. instrumentationtestrunner