介绍
为了保证APP的质量，有一些自动化测试也是很重要的。很长一段时间Android Developement Tools缺少了对自动化测试的支持。但是最近Google让开发者们可以更容易的接入这些测试了。
很多旧的Framework已经升级，而新的Framework也可以保证我们可以在APP和Library中访问这些。我们不仅仅可以在Android Studio中执行这些测试任务，也可以在命令行中执行，比如说通过Gradle。
Unit tests
一个写的好的单元测试不仅仅能够保证质量，它也能让我们检查新的代码是不是会破坏原有的功能性代码。Android Studio和Gradle Android Plugin可以为单元测试提供支持，但是需要我们可以配置一些东西。
JUnit
JUnit是一个常用的单元测试Lib。它可以让写出来的单元测试很容易的理解。值得注意的是，这些特殊的单元测试只对业务逻辑测试有用，而与Android SDK相关的则不会生效。
在使用JUnit写单元测试之前，你需要创建一个为了tests的目录。这个目录可以叫做test，并且它应该和你的main目录同级。这个目录结构如下：
app
└─── src
├─── main
│ ├─── java
│ │ └─── com.example.app
│ └───res
└─── test
└─── java
└─── com.example.app
你可以创建一个测试的Class在src/test/java/com.example.app中
为了使用最新的JUnit，可以使用JUnit版本4，在test构建中添加如下依赖关系：
dependencies {
testCompile 'junit:junit:4.12'
}
值得注意的是，我们使用testCompile，而不是compile。使用testCompile会保证只有在tests中该依赖才会被构建进去，而其他的版本则不会。在Dependencies中加入testCompile不会在Release的APK中编译，如果需要在一些特殊的BuildType或者ProductFlavors中加入配置，那么可以使用test-only的依赖来指定构建。
例如，如果你希望在付费版本加入JUnit测试，可以添加如下代码块：
dependencies {
testPaidCompile 'junit:junit:4.12'
}
当所有的事情都设置好了后，就是时候开始写一些单元测试了。以下为一个添加两个数字的test函数。
import org.junit.Test;
import static org.junit.Assert.assertEquals;
public class LogicTest {
@Test
public void addingNegativeNumberShouldSubtract() {
Logic logic = new Logic();
assertEquals("6 + -2 must be 4", 4, logic.add(6, -2));
assertEquals("2 + -5 must be -3", -3, logic.add(2, -5));
}
}
通过执行gradle test来执行所有的单元测试。如果你希望在一个Build Variant中来执行这些测试，那么可以添加这个Variant的名字即可。如果只想在Debug版本进行测试，那么就可以执行gradlewtestDebug。如果单元测试失败了，那么Gradle就会在命令行打印出来失败日志。如果成功了，那么Gradle会打印出来BUILD SUCCESSFUL的日志。
如果某个test任务失败了，整个过程会立刻终止。也就意味着如果失败，所有的任务都不会执行。如果希望整个test流程都执行完的话，那么可以使用continue的Flag：
$ gradlew test --continue
我们也可以通过在一个正确的路径保存一个Test的类来在某个版本中执行Test任务。例如：如果我们希望在付费版本中测试特定的功能，则将该类文件放入src/testPaid/java/com.example.app目录下。
如果你不想执行整个测试流程，而只是执行一个特定的测试类，你可以使用test标志位：
$ gradlew testDebug --tests="*.LogicTest"
执行测试任务不仅仅只会执行Test，也会创建一个Test Report，而这个文件的路径就放在app/build/reports/tests/debug/index.html。这个Report可以帮助我们查看哪儿失败了，并且对于自动化测试非常有用。Gradle会为每一个Build Variant执行测试任务构建一个Report。
如果test任务执行成功，那么单元测试的报告就会如下：
Unit Test
我们可以直接使用Android Studio执行Test任务。当我们使用的时候，会在IDE中直接反馈，当任务失败的时候，则会出现错误码，如果任务成功的话，那么Run Tool Window会如下所示：
Run Tool Window
如果你想测试部分引用了Android特殊的类和资源的代码的话，那么普通的单元测试则不能使用。当执行这任务的时候，会出现java.lang.RuntimeException: Stub!错误。为了修复这个错误，我们需要手动实现每个Android SDK的方法，或者使用mocking框架。
幸运的是，一部分Lib已经处理好了Android SDK的问题。Robolectric这个Lib提供了一个Android功能测试的快捷的方式，并且不需要设备和模拟器。
Robolectric
我们可以使用Robolectric来编写使用Android SDK和资源的测试。而这些测试任务会跑在一个JVM中。这也就意味着它不需要在设备或者虚拟机上使用Android资源了。因此，这样也会对于APP或者Library的UI组件表现的测试会更加快速。
开始使用Robolectric之前，我们需要添加一些测试的Dependencies。在Robolectric之内，也需要包含JUnit，并且如果需要使用Support Library的话，你也需要使用Robolectric的shadow-support类：
apply plugin: 'org.robolectric'
dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
compile 'com.android.support:appcompat-v7:22.2.0'
testCompile 'junit:junit:4.12'
testCompile'org.robolectric:robolectric:3.0'
testCompile'org.robolectric:shadows-support:3.0'
}
Robolectric测试的类必须创建在src/test/java/com.example.app的目录下，就像常见的单元测试一样。不同的是，我们写的测试单元可以使用Android的类和资源。例如，这个测试单元可以使得一个TextView在一个Button点击后修改文案：
@RunWith(RobolectricTestRunner.class)
@Config(manifest = "app/src/main/AndroidManifest.xml", sdk = 18)
public class MainActivityTest {
@Test
public void clickingButtonShouldChangeText() {
AppCompatActivity activity = Robolectric.buildActivity(MainActivity.class).create().get();
Button button = (Button)activity.findViewById(R.id.button);
TextView textView = (TextView)activity.findViewById(R.id.label);
button.performClick();
assertThat(textView.getText().toString(), equalTo(activity.getString(R.string.hello_robolectric)));
}
}
Robolectric在Android Lollipop和兼容包中都有一些已知的问题。如果在执行的时候遇到缺失兼容包中的资源的话，可以通过下面的方式修复：
在Module中加入一个project.properties文件，并且加入下面这几行:
android.library.reference.1=../../build/intermediates/exploded-aar/com.android.support/appcompat-v7/22.2.0
android.library.reference.2=../../build/intermediates/exploded-aar/com.android.support/support-v4/22.2.0
这样能帮助Robolectric找到Support中的资源
Functional tests
功能测试用来测试App中的一些组件是否与预期一样进行工作的。例如，你可以创建一个功能性的测试：点击一个Button打开一个新的Activity。Android提供了一些功能性测试的框架，但是最简单的还是使用Espresso框架。
Espresso
Espresso Library通过Android Support仓库提供。所以可以通过SDK Manager安装。为了在设备上进行测试，我们需要定义一个test runner。通过testing support library，Google提供了一个名为AndroidJUnitRunner的test runner，它可以帮我们在Android设备上运行JUnit Test类。Test Runner会将App的Apk和test的APK安装到该设备上，并且执行所有的test，然后将test结果生成到report中。
以下是如何设置test runner：
defaultConfig {
testInstrumentationRunner"android.support.test.runner.AndroidJUnitRunner"
}
我们在使用Espresso前配置一些依赖关系：
dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
compile 'com.android.support:appcompat-v7:22.2.0'
androidTestCompile 'com.android.support.test:runner:0.3'
androidTestCompile 'com.android.support.test:rules:0.3'
androidTestCompile 'com.android.support.test.espresso:espresso-core:2.2'
androidTestCompile 'com.android.support.test.espresso:espresso-contrib:2.2'
}
我们需要引用test support library和espresso-core来启动Espresso。最后一个依赖espresso-contrib是Espresso的一个补充库，而不是核心库。
这些依赖使用androidTestCompile进行配置，而不是testCompile。这也就是单元测试和功能测试之间的区别。
如果你现在执行这些测试构建，则会出现以下错误：
Error: duplicate files during packaging of APK app-androidTest.apk
Path in archive: LICENSE.txt
Origin 1: ...\hamcrest-library-1.1.jar
Origin 2: ...\junit-dep-4.10.jar
这个错误指的是Gradle不能完成构建，因为有多个相同的文件。幸运的是，它只是一个License描述，所以我们可以在构建中忽略它。这个错误包含了我们应该怎么做，我们可以在build.gradle中配置该选项：
android {
packagingOptions {
exclude 'LICENSE.txt'
}
}
一旦build.gradle文件配置完成后，就可以开始添加测试单元了。功能测试和常规的单元测试不同，它存放于一个其他的目录。就像依赖配置一样，我们需要使用androidTest取代test，所以正确的功能测试目录为src/androidTest/java/com.example.app。
例如，这个测试类检查是否这个TextView中的Text是否在MainActivity中：
@RunWith(AndroidJUnit4.class)
@SmallTest
public class TestingEspressoMainActivityTest {
@Rule
public ActivityTestRule<MainActivity> mActivityRule = new ActivityTestRule<>(MainActivity.class);
@Test
public void testHelloWorldIsShown() {
onView(withText("Hello world!")).check(matches(isDisplayed()));
}
}
在运行Espresso测试之前，需要确保有一个设备或者模拟器连上了。如果没有连接设备执行该任务的话，则会报错：
Execution failed for task ':app:connectedAndroidTest'.
>com.android.builder.testing.api.DeviceException:
java.lang.RuntimeException: No connected devices!
一旦连接了设备后，就可以通过gradlew connectedCheck来运行测试任务。这个任务会和connectedAndroidTest任务一起执行，在设备上执行Debug Build中的所有测试任务，并且创建DebugCoverageReport的报告。这个报告会在App目录下的build/outputs/ reports/androidTests/connected路径中。打开index.html来查看这个报告：
Report
功能测试报告会展示Device和Android的版本。你可以同时在多个设备上执行这些测试任务，所以这些设备信息会更好的查找到设备或者版本单独的Bug。
如果你希望通过Android Studio来获取测试反馈，可以通过IDE直接在run/denig的配置中设置。Android Studio ToolBar上有一个Configuration选项：
Edit Configuration
我们可以在Edit Configurations中设置一个新的Configuration，并且创建一个新的Android测试配置。选择Module并且指定instrumentation runner为AndroidJUnitRunner，如下图所示：
Espresso Configuration
一旦保存了配置后，就可以点击Run启动测试任务。
Test coverage
一旦你开始了Android Project的测试任务，它可以很方便的知道代码被多少测试单元覆盖。Jacoco是最受欢迎的测试工具。
Jacoco
覆盖率报告是否生效是非常容易的，只需要在Build Type中设置testCoverageEnabled = true即可。例如：
buildTypes {
debug {
testCoverageEnabled = true
}
}
当testCoverageEnabled打开时，执行gradlew connectedCheck就会生成覆盖率报告。而生成这个报告的任务名为createDebugCoverageReport。即使它没有在文档中记录，并且也没有在task列表中，而当你执行gradlew tasks时，它就会直接运行的。
然而，由于createCoverageReport依赖于connectedCheck，你不能单独运行这几个任务。connectedCheck这个任务也需要链接一个模拟器或者设备才能执行，并且生成test coverage report。
当这个任务被执行后，可以在app/build/outputs/reports/coverage/debug/index.html中找到覆盖率的报告。每一个Build Variant都有自己的覆盖率报告路径，因为每个Variant都有自己不同的tests。覆盖率测试报告如下：
Report
如果希望指定一个特殊的版本，那么在Build Type的配置代码块中加入Jacoco的版本定义：
jacoco {
toolVersion = "0.7.1.201405082137"
}
然而，Jacoco不需要显式的指定一个版本，Jacoco也可以工作。
网友评论