Androidtestcase
If you want to perform unit tests on the operations that require resource access or other operations dependent on the activity context, you need to expandAndroidtestcase interface (Extend this if you need to access resources or other things that depend on activity context.)
1
2 Public Class Testserviceapp Extends Androidtestcase
3 {
4 Public Void Testxxx () Throws Exception
5 {
6 // Specific test operationsCode, You can operate on the class and method to be tested
7 // Log. I ();
8 }
9 }
Configure androidmanifest. xml
Add a Unit Test Library at the same level as the activity tag within the application Tag:
<Uses-library Android: Name = "android. Test. Runner"/>
Add the following
1<Instrumentation Android: Name = "android. Test. instrumentationtestrunner"
2Android: targetpackage = "com. Aven. unittest" Android: Label = "tests for my app"/>
Targetpackage = "com. Aven. unittest" depends on the location of the test class. It is also mentioned in many Tutorials that it must be
<Manifest xmlns: Android ="Http://schemas.android.com/apk/res/android"
Package = "com. Aven. unittest"
The package names are the same.
Test
If you run the entire test file, right-click the file in the resource navigation bar and select "running mode" ---> "android JUnit test". If you only run a test function, right-click the cursor to locate the function name and select "running mode" ---> "android JUnit test", so that eclipse will deploy them on the android simulator, you can see the test information in the JUnit window. The red color indicates a problem in the test. You can find the problem as prompted.
Log output
To facilitate searching, you can use log in the test function to output some information.ProgramWhen running, you can clearly know that the Code is not running normally or has not achieved our intended purpose.
This is what the official documentation writes about this log.
Generally, use the log. V () log. D () log. I () log. W () and log. E () methods.
The order in terms of verbosity, from least to most is error, warn, info, debug, verbose. verbose shoshould never be compiled into an application during T during development. debug logs are compiled in but stripped at runtime. error, warning and info logs are always kept.
That is to say, we usually use the three methods, log. V () log. D () log. I () log. W () and log. E () to output information, indicating errors, warnings, information, debugging, and lengthy. Generally, log. I () can be used to output information. It is easy to use. You can give the output a flag at will. In the following example, the string mark myactivity is declared as a static String constant, which is also a commonly recommended method:
1 Private Static FinalString tag = "myactivity ";
2Log. V (TAG, "Index =" + I );
Then add a filter in the logcat view to quickly filter out the desired information: