我有个疑问困扰很多年的问题,Android 如何写单元测试

[unco020511]

我知道后端工程单元测试确实很方便(我做 java web 时也写了很多单元测试),生态和框架都很成熟.但 Android 这种严重依赖运行设备上下文,而且 UI 交互占据大部分逻辑的 project,到底如何正确做单元测试呢?

• 最好能有最佳实践的参考样例
• 如果能有相关学习资源更佳

[kera0a]

我是写 iOS 的，我之前也有很长一段时间，想给自己的项目加上完整的测试，但都无从下手，还尝试过一段时间开发 UI Test ，效果都不理想。
后来我悟了，普通的 MVC 开发这种逻辑 UI 混合在一起，就别想办法写测试了~ 天生不就适合

但自从我尝试使用 函数响应式架构 和 Redux 架构（分别使用）
用 Rx 响应式思想去构建我的 app, 我发现测试变了和后端一样简单，UI 只是数据流的一种状态显示，完全被剥离开了。
依赖注入让测试业务逻辑变的非常容易。
逻辑完全隔离开了 UI ，变的容易测试，并且很容易发现写的不好的地方，（如果发现某块代码不容易测试，那大概率是写的不好，需要改进写法）

所以推荐你尝试寻找一些安卓的 UI 逻辑分离的设计架构，不要在 UI 逻辑已经严重藕合的项目里尝试写测试了~

[3dwelcome]

分两种情况。

第一白盒测试，按照 google android unittest 的规范来开发，就是给测试环境模拟一个上下文，要虚拟机对象，那就挂一个 JVM 当测试伴侣。这种需要导入一些 android 测试包(Robolectric Testing library)，对我个人来说相对麻烦一点，宁可选择第二种方式。

第二黑盒测试，学游戏开发，有大量的 UI 和状态需要保存。那就把用户所有的输入都记录下来，测试的时候把各种操作都回放。

影响测试代码效率的最重要一点，就是启动到断点之间速度快不快。游戏里有一种代码热加载的技术，可以不用每次冷启动程序，就能测试代码片段。还有一些自定义的游戏脚本命令辅助，可以事半功倍。

[Helsing]

分层，把 UI 层隔离好就好测试了