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]

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

[ai277014717]

写单元测试能提高产品质量，主要看公司主管有没有想法有没有预算。自己的话就不要折腾了。拿那么点工资没必要因为写个单测费神费力。

[masterAtyan]

@blless 理论上确实什么代码都可以写单测

[GoodRainChen]

@blless

[GoodRainChen]

@blless 不小心提前发出去了，客户端目前写单元测试最大的难点在于确定输入输出。输入是用户的操作，输出是界面的展示，以目前常见的框架来说，想要仿造用户输入还算简单，但是检验界面展示就非常困难。至于逻辑很少很少，几乎没有单元测试的价值

[masterAtyan]

@ShareDuck 主要讨论的是 android 端单测，后端由于业务逻辑繁杂，确实有必要用单测保证自己改完单测逻辑的正确性，但 android 端说到底逻辑层面上确实复杂性不高

[vjnjc]

首先你要让你的代码 testable，意思就是说代码要写的好，不要有全局变量或者 android 包的关联。这样的代码才适合单元测试。

然后某些逻辑有一定复杂性，比如我客户端有个加密逻辑，这个实现单元测试挺好的。像界面跳转，http 请求都不适合。

[masterAtyan]

@vjnjc 我比较赞同，android 平台无关的可以写单测，android 端单测给我最大的收益是注意区分平台相关性代码，将平台相关性代码解耦，只是解耦平台相关性代码并非需要单测才能保证

[yuriko]

虽然理论上都能写，而且 android 相关的代码谷歌也有给对应的打桩工具
但真的写起来太蛋疼，尤其客户端业务逻辑变化太快了，单测很多最后都是变成给自己平白无故增加劳动量
我更倾向于单纯整理测试用例然后人工测试

[hantsy]

@DeweyReed 国内要求写测试的公司估计不到 1%吧，个人多年前在公司上班的时候推广过 Junit，遭到一致反对。

Java 测试工具架构真的太成熟了。一般 Java EE 和 Spring 程序 Backend 都很好写测试。但个人也不喜欢写 Web UI 的测试，HTML WebDriver 之类，但这类传统的 MVC 项目现在基本遇不到了，基本都是用 REST API+ 前端 SPA 程序，REST 测试工具框架太多了。

至于 Android 这种 UI 为主写测试真不容易，国内写的人更少了。代码必须低耦合，每个类功能要足够简单清晰。说白了，要做软件设计的最基本的 SOLID。

[hantsy]

@vjnjc 跳转，HTTP 这些都可以 Mock 和 Spy，应该检测输入和输出是否正确。

[hantsy]

@likuku
@WispZhan 是的，比如 6 个月的项目，短期两三周可能看不到什么效果。但如果一开始就严格写测试（和写一些脚本，不断调整，实现项目 CI、CD 自动化），后来的开发才能越来越容易。

国内大多数团队都急于在一两个星期做界面（不好听的话，就一张皮）出来给领导看，后面代码量一上去，整个项目代码就成滥泥一样，天天加班就是拆东墙补西墙，哪有什么代码质量，Maintainable，Testable 可言。

至于说写测试是浪费时间的说法，以我的个人经验（你不必认同）可以说，不写测试，从一个项目整体生命周期计算，你 70%的时间都在浪费时间，而且代码根本没质量而言。

[20015jjw]

写 为什么不写 我知道的硅谷大公司都写

[masterAtyan]

@hantsy 不反对测试对工程质量的保证，但一个人的软件水平是逐步提升的，一开始架构可能设计的不够好，最简单的来说看了 阿里程序员手册，发现方法名，类权限，方法的权限（ private，public ）以前写的不够好，如果我们想换单测必须写的跟在换。

不可否认 Testable 的代码确实很优雅，但优雅的代码不一定非要通过写单侧实现，尤其是 android 端的单测难写又复杂，写起来可不不是 JUnit 这些成熟的框架可比。

写单测只是说能让你发现代码设计的不合理的地方，但怎么修改还是需要去阅读大量的开源项目（优雅的代码）才能知道怎么去修改。

只是说 android 端单测耗费时间长罢了，有这些时间我们不如多读一本书，多看写源码来的实在，单测在大公司其实是一种 KPI 导向的推动，我们写出优雅的代码，大部分是模仿优秀的项目，而不是写单测

[hantsy]

@20015jjw 应该是大小公司都会要求测试吧。。。但不尽一样，大公司，如 IBM 这种，除了基本程序员自己应该写测试外，一般项目都有要求用户界面层面的功能测试，基本上都是先由一些业务专家写的测试规范，然后有一些测试人员专门进行（大公司也有很多专业工具辅助的，比如 HP 的测试工具）功能测试 。

小公司 /Startup，更倾向 Geek 文化和 Engineering 文化，XP，TDD， 不断 Refactoring 等，工具优先，整个软件开发生命周期都是力求没人工干预，自动化。