这是一个创建于 2499 天前的主题，其中的信息可能已经有所发展或是发生改变。
android 端一般业务逻辑少，比较多的是 UI 和线程切换以及网络请求， 我更推崇自动化测试，在真机上自动化运行 apk，这样才能暴露更多的问题
 |
1
lihongjie0209 2018-01-25 14:37:09 +08:00  1
单元测试是测试方法级别的逻辑.
真机运行起码是集成测试以上了, 两个概念 |
 |
2
masterAtyan OP 我认为单元测试能暴露的问题太少了，接口返回值，真实 UI 展示都被单元测试框架模拟了，这样的测试到底有何意义，在我所经历的项目里，如果剔除网络获取和 UI，真正的逻辑层代码有多少，这部分代码真的有必要写单测吗，android 端不应该更注重 UI 的稳定性
|
 |
3
panpanpan 2018-01-25 15:35:17 +08:00
我觉得单元测试更大的作用是如果覆盖得好的话，改了代码逻辑之后跑一下就能之后该出 bug 没有
|
 |
4
DeweyReed 2018-01-25 15:39:06 +08:00
unit 很碎片。记得官方建议是 7 成 unit，2 成 instrumentation，1 成手动。复杂程度递增，各自负责不同的部分。如果测试都得都得跑在手机里，说明项目有问题（怕不是用了 MVC?
|
 |
5
changkong 2018-01-25 15:40:22 +08:00
我认错，我从来不写单测
|
 |
6
scriptB0y 2018-01-25 15:41:13 +08:00
我觉得不用写。单元测试就像 F1 赛车道两旁的轮胎，不是路两边一直有轮胎，而是在在可能爆炸的地方放几个。
|
 |
7
nullcc 2018-01-25 15:59:17 +08:00
看功能复杂程度吧，非常简单的功能不用写了，复杂点的可以考虑写，之后重构什么的也比较省事
|
 |
8
rockyou12 2018-01-25 16:05:21 +08:00
增删改查业务确实没必要写，写了也测不出问题
|
 |
9
likuku 2018-01-25 16:09:41 +08:00
养成 TDD 的习惯了，代码堆上去之后，越往后，真的会越来越省事...
|
 |
10
sammo 2018-01-25 16:11:34 +08:00
写测试和 TDD 是好习惯
|
|
11
masterAtyan OP 但 android 为了实行 TTD，冗杂了很多库，有时候为了解决多线程的单元测试，屏蔽 UI 展示，耗费大量的时间，我觉得这是无意义的消耗。
单元测试不应该简单易懂，一条单元测试条目，不应该简介明了吗？ 像是 android 里 Rxjava 线程切换，就需要考虑怎么屏蔽掉切换 android mainthread 的问题，这反而是单元测试本身越来越复杂，这样写出来的测试，不仅维护成本高，易读性还差，这是我遇到的问题 |
|
12
lihongjie0209 2018-01-25 16:33:09 +08:00
@masterAtyan #11 多线程的问题可以用单元测试测试出来?
|
|
13
masterAtyan OP 现在的解决方案是跑单测的时候将 rxjava 的 android mainthread 替换成 io thread （这样无形中增加了开发量，必须定义一个 interface 接口），反正单测跑在电脑上，根本没有 mainthread 的说法，至于有没有其他更好的方案就不得而知了。
|
|
14
DeweyReed 2018-01-25 18:57:47 +08:00
|
|
15
masterAtyan OP 有空看一下
|
 |
16
blless 2018-01-25 20:12:34 +08:00 via iPhone
有单元测试写了重构方便
|
|
17
masterAtyan OP 重构会涉及到函数名，参数，UI 样式，架构（ mvp，mvvm ）等，这样大部分单元测试都跑不通，无端增加了开发单元测试的成本
|
 |
18
WispZhan 2018-01-25 20:30:30 +08:00 via Android
|
|
19
blless 2018-01-25 22:09:39 +08:00
@masterAtyan 我不怎么写安卓 不过理论上可验证逻辑都可以写单元测试 ，讲真跟代码习惯有关吧。很多人的一个函数写得又臭又长，真的是难写。把函数拆分成单个可验证逻辑，单元测试只测试一小段代码就好写多了。
|
 |
20
ShareDuck 2018-01-26 00:11:18 +08:00 via Android
不写单元测试怎能放心改代码？
|
 |
21
ai277014717 2018-01-26 10:33:48 +08:00
写单元测试能提高产品质量，主要看公司主管有没有想法有没有预算。自己的话就不要折腾了。拿那么点工资没必要因为写个单测费神费力。
|
|
22
masterAtyan OP @blless 理论上确实什么代码都可以写单测
|
 |
23
GoodRainChen 2018-01-26 11:39:55 +08:00
|
|
24
GoodRainChen 2018-01-26 11:42:11 +08:00
@blless 不小心提前发出去了，客户端目前写单元测试最大的难点在于确定输入输出。输入是用户的操作，输出是界面的展示，以目前常见的框架来说，想要仿造用户输入还算简单，但是检验界面展示就非常困难。至于逻辑很少很少，几乎没有单元测试的价值
|
|
25
masterAtyan OP @ShareDuck 主要讨论的是 android 端单测，后端由于业务逻辑繁杂，确实有必要用单测保证自己改完单测逻辑的正确性，但 android 端说到底逻辑层面上确实复杂性不高
|
 |
26
vjnjc 2018-01-26 12:01:49 +08:00
首先你要让你的代码 testable，意思就是说代码要写的好，不要有全局变量或者 android 包的关联。这样的代码才适合单元测试。
然后某些逻辑有一定复杂性，比如我客户端有个加密逻辑，这个实现单元测试挺好的。像界面跳转，http 请求都不适合。 |
|
27
masterAtyan OP @vjnjc 我比较赞同，android 平台无关的可以写单测，android 端单测给我最大的收益是注意区分平台相关性代码，将平台相关性代码解耦，只是解耦平台相关性代码并非需要单测才能保证
|
 |
28
yuriko 2018-01-26 12:55:39 +08:00
虽然理论上都能写，而且 android 相关的代码谷歌也有给对应的打桩工具
但真的写起来太蛋疼，尤其客户端业务逻辑变化太快了，单测很多最后都是变成给自己平白无故增加劳动量 我更倾向于单纯整理测试用例然后人工测试 |
 |
29
hantsy 2018-01-26 21:58:36 +08:00
@DeweyReed 国内要求写测试的公司估计不到 1%吧，个人多年前在公司上班的时候推广过 Junit，遭到一致反对。
Java 测试工具架构真的太成熟了。一般 Java EE 和 Spring 程序 Backend 都很好写测试。但个人也不喜欢写 Web UI 的测试，HTML WebDriver 之类，但这类传统的 MVC 项目现在基本遇不到了，基本都是用 REST API+ 前端 SPA 程序，REST 测试工具框架太多了。 至于 Android 这种 UI 为主写测试真不容易，国内写的人更少了。代码必须低耦合，每个类功能要足够简单清晰。说白了，要做软件设计的最基本的 SOLID。 |
|
31
hantsy 2018-01-26 22:19:26 +08:00 1
|
 |
32
20015jjw 2018-01-27 04:46:55 +08:00 via Android
写 为什么不写 我知道的硅谷大公司都写
|
|
33
masterAtyan OP @hantsy 不反对测试对工程质量的保证，但一个人的软件水平是逐步提升的，一开始架构可能设计的不够好，最简单的来说看了 阿里程序员手册，发现方法名，类权限，方法的权限（ private，public ）以前写的不够好，如果我们想换单测必须写的跟在换。
不可否认 Testable 的代码确实很优雅，但优雅的代码不一定非要通过写单侧实现，尤其是 android 端的单测难写又复杂，写起来可不不是 JUnit 这些成熟的框架可比。 写单测只是说能让你发现代码设计的不合理的地方，但怎么修改还是需要去阅读大量的开源项目（优雅的代码）才能知道怎么去修改。 只是说 android 端单测耗费时间长罢了，有这些时间我们不如多读一本书，多看写源码来的实在，单测在大公司其实是一种 KPI 导向的推动，我们写出优雅的代码，大部分是模仿优秀的项目，而不是写单测 |
Select Language