android 端真的需要写单测吗

[masterAtyan]

android 端一般业务逻辑少，比较多的是 UI 和线程切换以及网络请求， 我更推崇自动化测试，在真机上自动化运行 apk，这样才能暴露更多的问题

[lihongjie0209]

单元测试是测试方法级别的逻辑.
真机运行起码是集成测试以上了, 两个概念

[masterAtyan]

我认为单元测试能暴露的问题太少了，接口返回值，真实 UI 展示都被单元测试框架模拟了，这样的测试到底有何意义，在我所经历的项目里，如果剔除网络获取和 UI，真正的逻辑层代码有多少，这部分代码真的有必要写单测吗，android 端不应该更注重 UI 的稳定性

[panpanpan]

我觉得单元测试更大的作用是如果覆盖得好的话，改了代码逻辑之后跑一下就能之后该出 bug 没有

[DeweyReed]

unit 很碎片。记得官方建议是 7 成 unit，2 成 instrumentation，1 成手动。复杂程度递增，各自负责不同的部分。如果测试都得都得跑在手机里，说明项目有问题（怕不是用了 MVC?

[changkong]

我认错，我从来不写单测

[scriptB0y]

我觉得不用写。单元测试就像 F1 赛车道两旁的轮胎，不是路两边一直有轮胎，而是在在可能爆炸的地方放几个。

[nullcc]

看功能复杂程度吧，非常简单的功能不用写了，复杂点的可以考虑写，之后重构什么的也比较省事

[rockyou12]

增删改查业务确实没必要写，写了也测不出问题

[likuku]

养成 TDD 的习惯了，代码堆上去之后，越往后，真的会越来越省事...

[sammo]

写测试和 TDD 是好习惯

[masterAtyan]

但 android 为了实行 TTD，冗杂了很多库，有时候为了解决多线程的单元测试，屏蔽 UI 展示，耗费大量的时间，我觉得这是无意义的消耗。
单元测试不应该简单易懂，一条单元测试条目，不应该简介明了吗？
像是 android 里 Rxjava 线程切换，就需要考虑怎么屏蔽掉切换 android mainthread 的问题，这反而是单元测试本身越来越复杂，这样写出来的测试，不仅维护成本高，易读性还差，这是我遇到的问题

[lihongjie0209]

@masterAtyan #11 多线程的问题可以用单元测试测试出来?

[masterAtyan]

现在的解决方案是跑单测的时候将 rxjava 的 android mainthread 替换成 io thread （这样无形中增加了开发量，必须定义一个 interface 接口），反正单测跑在电脑上，根本没有 mainthread 的说法，至于有没有其他更好的方案就不得而知了。

[DeweyReed]

@masterAtyan Rxjava 的单元测试线程问题可以用一行 Rule 解决
https://stackoverflow.com/a/43356315/5507158

[masterAtyan]

有空看一下

[blless]

有单元测试写了重构方便

[masterAtyan]

重构会涉及到函数名，参数，UI 样式，架构（ mvp，mvvm ）等，这样大部分单元测试都跑不通，无端增加了开发单元测试的成本

[WispZhan]

看了楼上的回答发现，大多数人估计根本不考虑重构和代码维护了吧？！
就像
@nullcc
@likuku
@blless
说的。
单元测试对可维护的代码才是最大价值。重构的时候省事太多。

[blless]

@masterAtyan 我不怎么写安卓 不过理论上可验证逻辑都可以写单元测试 ，讲真跟代码习惯有关吧。很多人的一个函数写得又臭又长，真的是难写。把函数拆分成单个可验证逻辑，单元测试只测试一小段代码就好写多了。

[ShareDuck]

不写单元测试怎能放心改代码？