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, and there is no need to build 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, you will build a test apk that uses the Android test framework and can be deployed to your device to test your application. Here the bread contains unit tests, integration tests, and subsequent UI Automation tests.

This test sourceset should not contain androidmanifest.xml files, because this file will be generated automatically.

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

* Testpackagename

* Testinstrumentationrunner

* testhandleprofiling

* Testfunctionaltest

As you can see 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 test application's manifest file, the Targetpackage property value of the instrumentation node automatically uses the package name setting of the test app, even if the name is through Defaultconfig or build The type object is customized. This is also a reason why the manifest file needs to be automatically generated.

In addition, this test sourceset can also have its own dependencies.

By default, the application and his dependencies are automatically added to the classpath of the test app, but 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, it needs to be set up manually and cannot be run automatically.

Only one build type is currently being tested. The Debug Build Type is the default, but it can also be configured with the following customizations:

    Android {        ...        Testbuildtype "Staging"    }

5.2 Running Tests (run test)

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

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

* Verify that both the application and the test application are built (dependent on assembledebug and assembletest).

* Install both applications.

* Run these tests.

* Uninstall both apps.

If there are more than one connected device, all tests will run on all connected devices at the same time. If one of the tests fails, no matter which device is counted as failed.

All test results are saved as XML documents with the path:

Build/androidtest-results

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

Again, you can customize the 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 for testing an Android library project is similar to the way the project was applied.

The only difference is that the entire library, including its dependencies, is automatically added to the test application as a dependent library. The result is that the test apk not only contains its code, but also contains all the dependencies 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).

Androidtest task Change is just install (or uninstall) the test apk (because no other apk is installed).

The rest of the sections are similar.

5.4 Test reports (testing report)

When you run unit tests, Gradle prints a report in HTML format to make it easier to see the results.

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

5.4.1 Single projects (standalone project)

A project will automatically generate a test run. The default location is:build/reports/androidtests

This is very similar to JUnit's report location build/reports/tests, and other reports are usually located in build/reports/<plugin>/.

This path can also be customized in the following ways:

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

The report will merge the test results running on different devices.

5.4.2 Multi-projects reports (Multi-project report)

In a multi-project with multiple applications or multiple library projects, it may be useful to generate a report file to record all tests when running all the tests simultaneously.

To do this, you need to use another plugin in the same dependent file (referring to a dependent file that uses the Android Gradle plugin). You can add it 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 directory, for example, in a Build.gradle file that is in the same directory as the Settings.gradle file.

After that, navigate to the project root in the command line and enter the following command to run all the tests and consolidate all the reports:

Gradle Devicecheck mergeandroidreports--continue

Note: The--continue option here will allow all tests to fail even if any one of the sub-projects fails to run. Without this option, the first failed test will terminate the run of all tests, which 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)

Starting with version 0.7.0, you can run lint for a specific variant version of the project, or you can run lint for all variant versions. It will generate a report describing which version of the variant has the problem.

You can configure lint with the following lint options. Typically you only need to configure a subset of them, and the following lists all the options that you can use:

    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 '}