sdk测试是用来干什么的（sdk测试是用来干什么的呢）



1. 在build.gradle中添加以下依赖：

• 基础配置

• 如果项目里有用到support-v4包，需要如下配置

• 关于MultiDex
  Robolectric是运行在JVM上的，所以也就没有“MultiDex”这回事，如果我们的工程里使用了它，还需如下配置：

它hook了MultiDex的实现，让它在install的时候啥也不干。

1. 通过注解设置测试类的test runner

1. Mac及Linux用户必须注意如下配置

在Mac以及Linux上，第一次使用时，经常会出现一个很诡异的问题，会告诉我们如下错误：

设置JUnit的Working directory

1. Android Studio 3.0注意事项
   如果Android Studio是3.0及以上版本的，需要加上以下配置，否则运行不起来，会一直报错。

场景：我们有一个Activity，里面有一个Button，点击该Button跳转到另外一个Activity。
测试目的：验证用户点击该Button后，确实是跳转到了我们指定的Activity。
具体的布局文件以及Activity代码如下：

测试代码如下：

第一次运行需要比较长的时间，主要是从远程仓库下载robolectric所需的依赖库到本地，请耐心等待即可。

可以通过@Config注解来配置Robolectric运行时的行为。这个注解可以用来注释类和方法，如果类和方法同时使用了@Config，那么方法的设置会覆盖类的设置。如果你有很多测试类都采用同样的配置，那么你可以创建一个基类，通过@Config注解配置该基类，那么其他子类都能共享该配置。

7.4.1 配置constants

使用@RunWith(RobolectricTestRunner.class)时，必须要指定@Config(constants = BuildConfig.class)，这样它会从build/intermediates/目录下找到manifest、assets、resource等目录并加载相应的资源。

如上图所示，指定该配置后，Robolectric才会加载图中所示文件夹中对应的资源，否则就无法加载manifest、assets、resource等资源，测试也跑不起来。

7.4.2 配置SDK版本

7.4.3 配置Application

前面说过，在方法上也可以使用@Config来配置，如果类级别与方法级别同时有@Config配置，方法级别上的配置会覆盖类级别的配置。

7.4.4 配置resource、assets、manifest路径

前面介绍配置constants属性时，Robolectric会自动加载build/intermediates目录下的资源文件，可以使用以下配置使Robolectric加载特定的资源文件。

这里的路径很容易令人迷惑，必须要说明几点：

• 如果使用了@Config(constants = BuildConfig.class)，资源文件的路径会固定为build目录。避免constants配置与自定义manifest配置一起使用，否则后者配置会不生效。
• manifest设置的目录base于Unit Test Config里面的”Working Directory”，具体如7.2里的图“设置JUnit的Working directory”所示。
• resourceDir、assetDir的目录base于manifest的父目录。

自定义manifest目录示意图

该例子配置了一个指定的AndroidManifest.xml文件以及assets文件目录，测试程序读取assets里test.txt文件内容并打印出来。manifest的相对路径就是“UnitTest”工程里的“app”模块所在的文件路径，assetDir的相对路径就是AndroidManifest.xml文件的父目录路径。

7.4.1 生命周期

修改下7.3里面的测试案例代码如下，在各个生命周期回调中修改Button的文本内容。

测试代码如下：

控制台打印结果如下所示：

7.4.2 setupActivity()与buildActivity()

前面的示例中看到有2种创建Activity的方式：

这2种方式有什么差别呢，查看setupActivity()的源码可以看到：

7.4.3 测试Activity的跳转

在前面7.3中是示例中已经展示了。

7.4.4 测试Toast

7.4.5 测试Dialog

7.4.6 测试资源文件

7.4.7 测试Fragment

顾名思义就是影子类，Robolectric定义了很多shadow class，用来修改或者扩展Android OS中类的行为。当一个Android中的类被实例化时，Robolectric会去寻找对应的影子类，如果找到了则会创建一个影子对象并与之相关联。每当Android类中的一个方法被调用时，Robolectric会保证其影子类中相应的方法会被先调用。这对所有的方法都适用，包括static和final类型的方法。

通过该方法几乎可以获取大部分Android类的shadow class，例如：

Shadow Classes

Shadows.shadowOf()方法不能作用于自定义shadow class，为了使Robolectric能够识别自定义shadow类，需要采用@Config注解，如下所示：

执行该测试方法，控制台打印结果如下：

从以上控制台打印结果中可以看到，welcome()方法实际执行的是ShadowCompany中的方法。

Shadowing Constructors

如果需要对构造函数进行shadow，必须实现__constructor__方法，并且该方法的参数必须与构造函数的参数一样。我们稍微修改前面的Company类以及ShadowCompany类，对其构造函数进行shadow。

这个时候再执行测试代码，返回结果如下，可以看到Company的构造函数并没有执行。

Getting access to the real instance

有时shadow类需要使用它们关联的真实对象，可以通过@RealObject注解声明一个属性来实现。

自定义shadow要点

1. @Implements注解指定需要对哪个类进行shadow；
2. @Implementation指定需要对哪个方法进行替换；
3. 使用__constructor__来对构造器进行替换；
4. @RealObject来引用真实的关联对象；

前面介绍JUnit4的时候讲到，JUnit4中有个叫Parameterized的test runner，能够实现参数化测试，同样Robolectric也提供了同样的功能。

运行结果如下：

1. 不支持JNI调用。凡是涉及到JNI调用的方法，都不能使用Robolectric来进行单元测试。对于复杂的应用，或多或少都会有JNI调用，可行的方案是设置一个全局变量来控制是否加载so库。

系列文章：
Android单元测试（一）：前言
Android单元测试（二）：什么是单元测试
Android单元测试（三）：测试难点及方案选择
Android单元测试（四）：JUnit介绍
Android单元测试（五）：JUnit进阶
Android单元测试（六）：Mockito学习
Android单元测试（七）：Robolectric介绍
Android单元测试（八）：怎样测试异步代码

版权声明：

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！

转载请注明出处，原文链接：https://www.xkablog.com/te-aq/17904.html