Android testing relationship

 

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, we should first add some knowledge: We learned so much before, but we did not see the core class instrumentationtestsuite in our test example.
(This class is equivalent to the container in the test unit. All testcase needs to be managed with testsuite.) Why? Because the android SDK has a deep "packaging" for this part, it exactly has this middle layer, so we didn't see the container testsuite. Next we will introduce this middle layer.

Android. Test. suitebuilder

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

17:49:30 upload

Download Attachment
(23.85 KB)

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

17:49:37 upload

Download Attachment
(64.49 KB)

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. footestcom. Android. Foo/Android. Test. instrumentationtestrunner

Run a function in a testcase:
ADB shell am instrument-w-e class com. Android. Foo. footest # testfoocom. Android. Foo/Android. Test. instrumentationtestrunner

Test multiple testcase at the same time:
ADB shell am instrument-w-e classcom. Android. Foo. footest, Com. Android. Foo. tootestcom. 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?

17:49:34 upload

Download Attachment
(12.21 KB)

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:

17:49:33 upload

Download Attachment
(42.95 KB)

The main function interfaces are listed as follows:

17:49:31 upload

Download Attachment
(24.66 KB)

Typical use process of instrumentationtestrunner:

• Write test cases. The test cases are basically inherited from the following classes:
  • L activityinstrumentationtestcase
  • Activityunittestcase
  • Androidtestcase
  • Applicationtestcase
  • Instrumentationtestcase
  • Providertestcase
  • Servicetestcasesinglelaunchactivitytestcase
• Define an instrumentation in androidmanifest. xml and specify the name of the tested package in the targetpackage attribute;
• Run instrumentation and use "ADB shell am instrument-W" to run all tests (except performance tests );
• 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;
• 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;
• 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:

17:49:35 upload

Download Attachment
(58.66 KB)

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
{
@ Override
Public testsuite getalltests ()
{
Log. I ("apidemosrunner", "apidemosrunner: getalltests ()");
Return new testsuitebuilder (apidemosrunner. Class)
. Includeallpackagesunderhere ()
. Build ();
}

@ Override
Public 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.