mockitoandroid

㈠ android studio怎么进行单元测试

注意：这里以mac下的操作为例子。
新建一个Android 工程，参考下图的步骤。
1、填写项目名称："LocalUnitTestDemo"
2、选择sdk版本，这里选择api16，android 4.1
3、添加一个空的activity页面，blank activity
4、确认添加的activity页面名称等。

工程建立好之后，切换项目到Project模式，mac下按‘Command’+‘1’可以看到新生成的代码目录结构。
"app/src/main/java",这个目录下是放我们app的源代码；
"app/src/test/java"，这个目录下是放我们本地单元测试的源代码。

注意：如果工程建立好之后提示：‘failed to resolve：junit：junit：4.12’,如下图1。
这时需要修改我们工程的build.gradle
打开左侧的Project侧边栏，找到我们的工程build.gradle，图2，修改红框里的两个"jcenter()"依赖库为：
maven { url "http://jcenter.bintray.com/" }maven { url "http://repo1.maven.org/maven2/"}
这两句话。结果如图三：

4
打开我们模块app的build.gradle,图1，添加两个依赖项：
testCompile 'org.mockito:mockito-core:1.10.19'
androidTestCompile 'org.hamcrest:hamcrest-library:1.1'

㈡ 进行单元测试时android模拟器会不会启动

测试androidsdk 开发单元测试
在安卓模拟器或者真机上跑测试用例速度很慢。构建、部署、启动app，通常需要花费一分钟或者更久。这不是TDD（测试驱动开发）模式.Robolectric提供一种更好的方式。
可能你一直尝试在java IDE中使用junit或者testng直接跑测试用例，但是一直报java.lang.RuntimeException: Stub!异常。
这个异常是因为在jdk中没有android运行环境。而现在Robolectric这款android单元测试工具，模拟了android sdk中的jar包，可以直接在jvm中运行测试用例，这样就大大节省了时间。一个Robolectric测试用例如下：
// Test class for MyActivity @RunWith(RobolectricTestRunner.class) public class MyActivityTest { @Test public void clickingButton_shouldChangeResultsViewText() throws Exception { Activity activity = Robolectric.buildActivity(MyActivity.class).create().get(); Button pressMeButton = (Button) activity.findViewById(R.id.press_me_button); TextView results = (TextView) activity.findViewById(R.id.results_text_view); pressMeButton.performClick(); String resultsText = results.getText().toString(); assertThat(resultsText, equalTo("Testing Android Rocks!")); } }

在安卓模拟器或者真机上跑测试用例速度很慢。构建、部署、启动app，通常需要花费一分钟或者更久。这不是TDD（测试驱动开发）模式.Robolectric提供一种更好的方式。
可能你一直尝试在java IDE中使用junit或者testng直接跑测试用例，但是一直报java.lang.RuntimeException: Stub!异常。
这个异常是因为在jdk中没有android运行环境。而现在Robolectric这款android单元测试工具，模拟了android sdk中的jar包，可以直接在jvm中运行测试用例，这样就大大节省了时间。一个Robolectric测试用例如下：
// Test class for MyActivity
@RunWith(RobolectricTestRunner.class)
public class MyActivityTest {

@Test
public void clickingButton_shouldChangeResultsViewText() throws Exception {
Activity activity = Robolectric.buildActivity(MyActivity.class).create().get();

Button pressMeButton = (Button) activity.findViewById(R.id.press_me_button);
TextView results = (TextView) activity.findViewById(R.id.results_text_view);

pressMeButton.performClick();
String resultsText = results.getText().toString();
assertThat(resultsText, equalTo("Testing Android Rocks!"));
}
}

SDK，Resource和Native Method模拟
Robolectric可以处理控件展示、资源加载和很多使用native C实现的真机上的其他功能。所以我们可以使用Robolectric来模拟真机上的大部分操作。我们可以很方便地获取Robolectric的源码，直接查看它的模拟机制，所以使用Robolectric，我们也可以模拟错误条件和一些真实的传感器信号。
脱离模拟器执行测试用例
Robolectric允许我们在项目工程中或者持续集成（CI如hudson、jenkins）中使用jvm来执行测试用例，所以就省掉了打包、安装的过程，将测试用例的执行时间由分钟级降到秒级。
不再需要Mock框架
使用一些Mock框架，如Mockito或者Android Mock等，可以模拟出android运行环境，达到和Robolectric相同的效果。这是一个有效的方法，但是使用这种方法写出的测试用例，很多情况下就是开发代码的反实现。
Robolectric的测试风格更偏向于黑盒测试，robolectric式的测试用例更加关注与app的表现，而不是android运行环境的实现，所以使用robolectric写出的测试用例更有效。当然这也是看测试人员的喜好，如果喜欢可以同时使用Robolectric和mock框架。

㈢ Android单元测试之Mockito的使用

Mockito最大的特点是模拟依赖，

打桩的意思是对mock出来的对象进行操作，比如模拟返回值

比如
Calculator文件有方法

通过单元测试可以模拟更改返回值

输出 hello,leory

doReturn主要是对无法用thenReturn的情况，比如返回值void

输出 小明

通过 verify(T mock) 验证发生的某些行为 。

举个栗子
参数为 aynInt()

参数包含某个string

参考 Android单元测试(二)：Mockito框架的使用

㈣ as中的mockable-android-24.jar有用吗

本地Unit Test由于使用Junit4，因此与Java中的单元测试区别不大，可以灵活的使用Mockito来模拟调用Android的API。同时Android Studio在构建APP时，也会自动生成一个MockableAndroid.jar来支持这一需求。
Instrument类型测试由于类库较多，因此使用的Runner也有所不同

㈤ 如何一步步实现AndroidCI

一步步实现Android CI

Android上的CI构建链与其它平台一致，依然包含Compilation, Testing, Inspection,
Deploying阶段，每一个阶段的Feedback的都保持对整个团队透明。

2、添加Function Test

Android为大家提供了一套集成测试框架Android integration testing
framework。但此框架未集成Cucumber，这导致每增加一个Function Test都需要较大的开发和维护工作。这样高成本的实现Function
Test将大大延缓开发进度，最终因为项目进度的原因导致Function Test被丢弃。产生这样的后果那必然是不愿意看到的。

目前Android平台下已经出现多种Functiong Testing测试工具，如Native Driver, Robotium,
Calabash等。在尝试对比后，最终选择了Calabash Android作为解决方案。Calabash
Android是Cucumber在Android平台的实现，使用Ruby书写Function Test，并提供了一组操作Anadroid App元素的API。

3、添加UI Test

Android在新近退出了UI测试工具UIAutomator。此工具仅支持Android4.1及以上平台，鉴于目前市场上2.3和4.0版本仍占主导的情况来看，目前还无法满足大家的需要。另外应用该工具实现UI测试的开发成本还较高，笔者暂不推荐使用此工具，但应该关注其发展。

另外基于录制回放机制的测试方法同样可以进行UI测试。但录制回放的方法在面对功能快速迭代时，维护工作会急剧增加，而这个维护成本可以说是很难承受的，所以在此也不会将这种测试方法集成至CI中。

目前来看Android中UI测试还无令人满意的方法。若对UI成功比较看重，可以投入精力应用UIAutomator进行UI测试。

Best Practice:

*
将测试按照单元测试，组件测试，功能测试和系统测试进行划分。单元测试应该在每次提交时触发执行，其它的测试根据运行时间长短和重要程度可以每次提交触发执行或者定时周期执行。

* 将运行较快的测试优先执行。

* 让功能测试能够重复执行。否则维护成本太高，会被舍弃。若是后台数据导致不可重复，可以将数据抽象成为数据集，在每次运行前进行重置。

* 书写测试时每一个assert只做一种判断，这样可以明确每次测试的目的，并且可以快速定位测试失败愿意。

步骤 3：持续检查持续检查是对于代码本身检测和反馈。检测主要通过对代码静态分析验证代码风格，编程规范，代码复用，代码语言中的Best Practice等多个维度的代码质量。

Sonar作为一个开源的代码质量检测工具，涵盖了7项代码质量检测方式。这充分满足Android平台下对于代码质量的检测分析。Sonar分为两部分一部分是代码分析工具，另一部分是数据分析展示的Server。

Best Practice:

* 将测试覆盖率，代码分析结果透明化

* 持续降低代码复杂度

* 持续的促进设计的演进

* 持续的维护代码结构

* 持续减少代码重复

步骤 4：持续部署

由于Android App采用用户手动从Appstore自行下载安装的方式发布，使得Android
App无法直接部署至用户手机中。另外Appstore需要对于上线的App进行审核，不能持续进行Release。因而Android中持续部署将以持续发布可安装包为目标。

在以上目的下，只需根据自身项目资源找到合适的安装包管理工具即可。如本文采用Dropbox来管理所有安装包。

Dropbox作为一个云存储平台，在Android终端设备上可以轻松下载存放在其中的文件，同时上传安装包也可以交由Dropbox自己完成。

步骤 5：持续反馈

反馈是所有改进的开始，必须要让所有人获取到他们所关心的反馈信息，才能实施改进。持续反馈的目的就是让所有人都掌握项目健康状况。项目所有人事实都是有意愿知道项目当前的健康状况的，那CI就应该将项目的情况做到透明，并将不同的反馈通知到各相关的成员。

CI不同阶段产生了不同维度的反馈，如单元测试报告，测试覆盖率等。本实践中将这些反馈都透明的展示在项目首页中。之所以没有将这些反馈再以邮件的方式通知所有人，是因为团队成员已经养成了查看CI的习惯。

如果说只给所有人发一封邮件说明项目状况，那必然是告诉所有人“CI所有步骤是否都返回正确？”。这样一个反馈，包含了编译正确，所有测试通过，安装包已经准备完毕等重要信息。有必要让所有人都知道这个信息，特别是在CI执行失败的时候。Jenkins自身已经提供一个简单有效的透明化方法，以项目为蓝色表示通过，红色表示有步骤失败。

反馈的通知方式有很多种，不一定要采用邮件通知的方式。可以寻找更加有趣的方式，如果播放音乐和设置警报灯。在每一次Build成功或失败后都播放一段有趣的音乐，打开不同颜色的警报灯，这两种方法都是是一种简单有效的方式，可以让项目所有人都获取到最为关键的信息。

㈥ 如何在android源码里设置mockito

它分成以下几个步骤： 建立mock； 将mock和待测试的对象连接起来； 在mock上设置预期的返回值； 开启replay模式，准备记录实际发生的调用； 进行测试； 验证测试结果，调用顺序是否正确，返回值是否符合期望；

㈦ # mockito2 坑 集成使用 Caused by: org.mockito.exceptions.base.MockitoException:

解决方案 compile "org.mockito:mockito-android:2.+" 对应 androidTest
解决方案 compile "org.mockito:mockito-core:2.+" 对应 test
选一个 不能共存
问题描述:
github issues

㈧ Android Studio 2.1 Preview 有哪些更新内容

1. 支持Java 8 语言特性和新的 Jack compiler编译器 更新了一个新的项目向导用于配置生成针对Android N 预览版本的项目。

2. 支持Android Emulator 2.0 Beta，并且为Android N 预览版本系统映像提供了最佳的性能。
   （温馨提醒）
   Android Studio 2.1在开发Android N Preview 版本的时候也带来了以下几个问题：
   立即运行Instant Run 不能和Jack compiler编译器兼容，所以如果使用Jack compiler 编译器Instant Run则会设置为不可用 （如果不使用Java 8特性完全没必要使用Jack compiler编译器）。 那些可查看.class 文件的工具 （例如 JaCoCo， Mockito，和一些lint检查） 目前与 Jack compiler 编译器不兼容。 本地调试（LLDB）目前在 Android N Preview 版本下不能工作。