Android Gradle Plugin Guide (iv)--Test

Original address: Http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Testing

5, testing (test)

Building a test program has been integrated into the application project, there is no need to set up a test project specifically.

5.1 Basics and configuration (basic knowledge and configurations)

As mentioned earlier, the Androidtest Sourceset is adjacent to main Sourceset, and the default path is under src/androidtest/.

In this test sourceset, a test apk is built using the Android test framework and can be deployed to the device to test the application. This includes unit test, integrated test. And maybe the UI itself to take the initiative to test.

This test sourceset should not include the Androidmanifest.xml file, as this file will be generated on its own initiative.

The following values may be used in the test application configuration:

* Testpackagename

* Testinstrumentationrunner

* testhandleprofiling

* Testfunctionaltest

As shown earlier, these configurations are configured in the Defaultconfig object:

    Android {        Defaultconfig {            testpackagename "Com.test.foo"            Testinstrumentationrunner " Android.test.InstrumentationTestRunner "            testhandleprofiling true            testfunctionaltest True        }    }

In the manifest file of the test application. The Targetpackage property value of the instrumentation node is actively using the package name setting of the test application itself. Even if the name is defined by the Defaultconfig or build type Object itself. This is also a reason why manifest files need to be generated on their own initiative.

Other than that. This test sourceset can also have its own dependence.

By default, the application and his dependencies will be included in the classpath of the test application on their own initiative. But it can also be extended by:

    dependencies {        androidtestcompile ' com.google.guava:guava:11.0.2 '    }

The test application is built by Assembletest task.

Assembletest does not depend on the assemble task in main. Manual execution is required and cannot be performed on its own initiative.

Only one build type is tested at the moment. The Debug Build Type is the default, but it can also be configured by following its own definition:

    Android {        ...        Testbuildtype "Staging"    }

5.2 Running tests (test performed)

As mentioned earlier. The iconic task Connectedcheck requires a connected device to start.

This process relies on the androidtest task, so the androidtest will be executed. This task will perform the following:

* Verify that applications and test applications are built (dependent on assembledebug and assembletest).

* Install both applications.

* Perform these tests.

* Uninstall both apps.

Suppose there are more than one connected device. Then all tests will be executed at the same time on all connected devices. Let's say that one of the tests failed, no matter which device failed.

All test results are saved as XML documents. The path is:

Build/androidtest-results

(This is similar to JUnit's execution results saved in build/test-results)

The same, it can also define its own configuration:

    Android {        ...        testoptions {            Resultsdir = "$project. Builddir/foo/results"        }    }

The android.testOptions.resultsDir here will be obtained by Project.file (String).

5.3 Testing Android Libraries (Test Android Library)

The method of testing the Android library project is similar to the way the project was applied.

The only difference is that the entire library (including its dependencies) is actively added to the test application as a dependent library. The result is that the test apk not only includes its code, but also the entire dependency of the library project itself and the library.

The manifest of the library are combined into the manifest of the test application (as some projects refer to the shell of the library).

The Androidtest task change is simply to install (or uninstall) the test apk (as no other apk is installed).

The rest of the section is similar.

5.4 Test reports (test report)

When executing the unit test, Gradle will output a report in HTML format for easy viewing of the results.

Android plugin is also based on this and extends the HTML report file, which merges all connected device reports into a single file face.

5.4.1 Single projects (standalone project)

A project will generate test execution on its own initiative. The default location is:build/reports/androidtests

This is similar to the location of JUnit reports Build/reports/tests, and other reports are usually located in build/reports/<plugin>/.

This path can also be defined by itself in the following way:

    Android {        ...        testoptions {            Reportdir = "$project. Builddir/foo/report"        }    }

The report will be combined to perform the test results on different devices.

5.4.2 Multi-projects reports (Multi-project report)

In a multi-project that is configured with multiple applications or multiple library projects. When performing all tests at the same time, it may be useful to generate a report file to record all the tests.

To achieve this, there is also a plugin in the same dependent file (referring to the dependency file using the Android Gradle plugin). Can be added in the following ways:

    Buildscript {        repositories {            mavencentral ()        }        dependencies {            classpath ' com.android.tools.build:gradle:0.5.6 '        }    }    Apply plugin: ' android-reporting '

This must be added to the project's root folder. For example, the same folder as the Settings.gradle file in the Build.gradle file.

After that, navigate to the project root folder on the command line and enter the following command to perform all tests and merge all reports:

Gradle Devicecheck mergeandroidreports--continue

Note: The--continue option here will agree to all tests. Even if any one of the execution failures in the subproject does not stop.

Assuming that there is no option, the first failed test will terminate all test executions. This may result in some projects not performing their tests.

5.5 Lint Support (Lint supported, translator Note: Lint is a tool that can check for problems with Android projects)

Start with the 0.7.0 version number. You can perform lint for a specific variant version number in the project. Lint can also be executed for all variant version numbers.

It will generate a report describing the issue of which variant version number is present.

You can configure lint with the lint option below.

Typically you just need to configure a subset of them. All available options are listed below:

    Android {lintoptions {//set to True-turn off analysis progress reporting by lint Qu IET true/If True, stop the Gradle build if errors is found abortonerror false//If T Rue, only Report errors Ignorewarnings true/If True, emit full/absolute paths to files with error S (True by default)//absolutepaths true/If true, check all issues, including those that is off By default checkallwarnings true//If true, treat all warnings as errors Warningsaserror            s true//Turn off checking the given issue ID ' s disable ' typographyfractions ', ' typographyquotes ' Turn on the given issue ID ' s enable ' rtlhardcoded ', ' rtlcompat ', ' rtlenabled '//Check *o Nly* the given issue ID ' s check ' newapi ', ' inlinedapi '//If True, don ' t include source code lines I      n the error output      Nolines true/If True, show all locations for a error, do not truncate lists, etc.            ShowAll true//Fallback lint configuration (default severities, etc.)            Lintconfig file ("Default-lint.xml")//If True, generate a text report of issues (false by default) Textreport true//location to write the output; Can be a file or ' stdout ' textoutput ' stdout '//If true, generate the XML report for use by for exam PLE Jenkins Xmlreport false//file to write report to (if not specified, defaults to Lint-results.x ML) xmloutput file ("Lint-report.xml")//If True, generate an HTML report (with issue explanations, SourceCode, etc) htmlreport true//optional path to report (default would be is lint-results.html in th  e builddir) htmloutput file ("lint-report.html")//set to True to any release builds run lint onIssues with severity=fatal//and abort the build (controlled by Abortonerror above) if fatal issues is found            Checkreleasebuilds true//Set the severity of the given issues to fatal (which means they would be            Checked during release builds (even if the lint target is not included) fatal ' Newapi ', ' Inlineapi '  Set the severity of the given issues to error error ' Wakelock ', ' textviewedits '//Set The severity of the given issues to warning warning ' resourceascolor '//Set The severity of the GI Ven issues to ignore (same as disabling the check) Ignore ' typographyquotes '}

Android Gradle Plugin Guide (iv)--Test