zoukankan      html  css  js  c++  java
  • Android Gradle Plugin指南(四)——測试

    原文地址:http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Testing


    5、Testing(測试)


    构建一个測试程序已经被集成到应用项目中,没有必要再专门建立一个測试项目。


    5.1 Basics and Configuration(基本知识和配置)


    正如前面所提到的,紧邻main sourceSet的就是androidTest sourceSet,默认路径在src/androidTest/下。

    在这个測试sourceSet中会构建一个使用Android測试框架,而且能够部署到设备上的測试apk来測试应用程序。这里面包括单元測试,集成測试。和兴许UI自己主动化測试。

    这个測试sourceSet不应该包括AndroidManifest.xml文件,由于这个文件会自己主动生成。


    以下这些值可能会在測试应用配置中使用到:

        * testPackageName

        * testInstrumentationRunner

        * testHandleProfiling

        * testfunctionalTest


    正如前面所示,这些配置在defaultConfig对象中配置:

        android {
            defaultConfig {
                testPackageName "com.test.foo"
                testInstrumentationRunner "android.test.InstrumentationTestRunner"
                testHandleProfiling true
                testFunctionalTest true
            }
        }

    在測试应用程序的manifest文件里。instrumentation节点的targetPackage属性值会自己主动使用測试应用的package名称设置。即使这个名称是通过defaultConfig或者Build Type对象自己定义的。这也是manifest文件须要自己主动生成的一个原因。


    另外。这个測试sourceSet也能够拥有自己的依赖。

    默认情况下,应用程序和他的依赖会自己主动加入的測试应用的classpath中。可是也能够通过下面来扩展:

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

    測试应用通过assembleTest task来构建。

    assembleTest不依赖于main中的assemble task。须要手动设置执行,不能自己主动执行。


    眼下仅仅有一个Build Type被測试。默认情况下是debug Build Type,可是这也能够通过下面自己定义配置:

        android {
            ...
            testBuildType "staging"
        }

    5.2 Running tests(执行測试)


    正如前面提到的。标志性task connectedCheck要求一个连接的设备来启动。

    这个过程依赖于androidTest task,因此将会执行androidTest。这个task将会执行以下内容:

        * 确认应用和測试应用都被构建(依赖于assembleDebug和assembleTest)。

        * 安装这两个应用。

        * 执行这些測试。

        * 卸载这两个应用。


    假设有多于一个连接设备。那么全部測试都会同一时候执行在全部连接设备上。假设当中一个測试失败,无论是哪一个设备算失败。


    全部測试结果都被保存为XML文档。路径为:

        build/androidTest-results

    (这类似于JUnit的执行结果保存在build/test-results)


    相同,这也能够自己定义配置:

        android {
            ...
    
            testOptions {
                resultsDir = "$project.buildDir/foo/results"
            }
        }

    这里的android.testOptions.resultsDir将由Project.file(String)获得。


    5.3 Testing Android Libraries(測试Android库)


    測试Android库项目的方法与应用项目的方法类似。


    唯一的不同在于整个库(包括它的依赖)都是自己主动作为依赖库被加入到測试应用中。结果就是測试APK不单仅仅包括它的代码,还包括了库项目自己和库的全部依赖。

    库的manifest被组合到測试应用的manifest中(作为一些项目引用这个库的壳)。


    androidTest task的变改仅仅是安装(或者卸载)測试APK(由于没有其他APK被安装)。


    其他的部分都是类似的。


    5.4 Test reports(測试报告)


    当执行单元測试的时候,Gradle会输出一份HTML格式的报告以方便查看结果。

    Android plugin也是基于此,而且扩展了HTML报告文件,它将全部连接设备的报告都合并到一个文件中面。


    5.4.1 Single projects(独立项目)


    一个项目将会自己主动生成測试执行。默认位置为:build/reports/androidTests


    这很类似于JUnit的报告所在位置build/reports/tests,其他的报告通常位于build/reports/<plugin>/。


    这个路径也能够通过下面方式自己定义:

        android {
            ...
    
            testOptions {
                reportDir = "$project.buildDir/foo/report"
            }
        }

    报告将会合并执行在不同设备上的測试结果。


    5.4.2 Multi-projects reports(多项目报告)


    在一个配置了多个应用或者多个库项目的多项目里。当同一时候执行全部測试的时候,生成一个报告文件记录全部的測试可能是很实用的。


    为了实现这个目的,须要使用同一个依赖文件(译注:指的是使用android gradle插件的依赖文件)中的还有一个插件。能够通过下面方式加入:

        buildscript {
            repositories {
                mavenCentral()
            }
    
            dependencies {
                classpath 'com.android.tools.build:gradle:0.5.6'
            }
        }
    
        apply plugin: 'android-reporting'

    这必须加入到项目的根文件夹下。比如与settings.gradle文件同个文件夹的build.gradle文件里。


    之后,在命令行中导航到项目根文件夹下,输入下面命令就能够执行全部測试并合并全部报告:

    gradle deviceCheck mergeAndroidReports --continue

    注意:这里的--continue选项将同意所有測试。即使子项目中的不论什么一个执行失败都不会停止。

    假设没有这个选项,第一个失败測试将会终止所有測试的执行。这可能导致一些项目没有执行过它们的測试。


    5.5 Lint support(Lint支持,译者注:Lint是一个能够检查Android项目中存在的问题的工具)


    从0.7.0版本号開始。你能够为项目中一个特定的Variant(变种)版本号执行lint。也能够为全部Variant版本号都执行lint。

    它将会生成一个报告描写叙述哪一个Variant版本号中存在着问题。


    你能够通过下面lint选项配置lint。

    通常情况下你仅仅须要配置当中一部分。下面列出了全部可使用的选项:

        android {
    
            lintOptions {
    
                // set to true to turn off analysis progress reporting by lint
                quiet true
                // if true, stop the gradle build if errors are found
                abortOnError false
                // if true, only report errors
                ignoreWarnings true
                // if true, emit full/absolute paths to files with errors (true by default)
                //absolutePaths true
                // if true, check all issues, including those that are off by default
                checkAllWarnings true
                // if true, treat all warnings as errors
                warningsAsErrors true
                // turn off checking the given issue id's
                disable 'TypographyFractions','TypographyQuotes'
                // turn on the given issue id's
                enable 'RtlHardcoded','RtlCompat', 'RtlEnabled'
                // check *only* the given issue id's
                check 'NewApi', 'InlinedApi'
                // if true, don't include source code lines in the error output
                noLines true
                // if true, show all locations for an 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 an XML report for use by for example Jenkins
                xmlReport false
                // file to write report to (if not specified, defaults to lint-results.xml)
                xmlOutput file("lint-report.xml")
                // if true, generate an HTML report (with issue explanations, sourcecode, etc)
                htmlReport true
                // optional path to report (default will be lint-results.html in the builddir)
                htmlOutput file("lint-report.html")
    
               // set to true to have all release builds run lint on issues with severity=fatal
    
               // and abort the build (controlled by abortOnError above) if fatal issues are found
    
               checkReleaseBuilds true
    
                // Set the severity of the given issues to fatal (which means they will 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 given issues to ignore (same as disabling the check)
                ignore 'TypographyQuotes'
            }
    
        }



  • 相关阅读:
    网络测量中基于Sketch方法的简单介绍
    Reading SBAR SDN flow-Based monitoring and Application Recognition
    Reading Meticulous Measurement of Control Packets in SDN
    Reading SketchVisor Robust Network Measurement for Sofeware Packet Processing
    ovs加dpdk在日志中查看更多运行细节的方法
    后缀数组
    (转载)LCA问题的Tarjan算法
    Codeforces Intel Code Challenge Final Round (Div. 1 + Div. 2, Combined) A. Checking the Calendar(水题)
    Vijos 1816统计数字(计数排序)
    卡特兰数
  • 原文地址:https://www.cnblogs.com/hrhguanli/p/5080892.html
Copyright © 2011-2022 走看看