最近在做一个看起来非常 “基本” 的工作：推进单元测试的实施与落地。一如既往，万事开头难。受到了很多阻力，也收到了很多问题。一个最普遍的问题就是：如何做好单元测试？这个问题看似非常 low，但想做好它实际上不是一件容易事。单元由很多细小的知识点和工作习惯构成，需要一定时间打磨。但是很多同学不是特别喜欢系统的学习，那么如何在很快的时间内得到 60 分呢。按照我的经验，总结了一个 cheat sheet，分享给大家。里边涉及的术语和技术以 Java 语言为主。
1.树立信念，认识到它的价值，才能真正做好。强扭的瓜不甜,从来没有见过大部分人心里不认同还能把一件事儿做好的团队。最近正三观最好的一篇文章就是马大爷的Is High Quality Software Worth the Cost?
2.不要补单测，同期建设才能发挥出它的价值，建议试试测试驱动开发的方式，习惯了你会感觉很爽，因为 TDD 一开始就会逼迫你做好设计。
3.不要隔山打牛。什么叫做隔山打牛呢？也就是 方法 A 调用方法 B，方法 B 调用方法 C，用调用 A 的方法去测试方法 C。这是最朴素的一种单元测试方式，也是极为错误的一种方式。 乍一看可以少写不少代码，相信我，量大了，时间长了，你 100% 会被自己玩死。每个方法都应该有自己的测试方法。
4.使用单元测试框架。main 方法里写测试然后再全部注释是大学一年级学生的做法。花半小时学习单元测试框架的使用方法吧。
5.使用 mock 框架隔离外部资源，一般跨进程就是外部资源了。什么 RPC，什么 DB 都是。快和稳定是单侧的一个基本要求。
6.使用 Rright-BICEP 法则，你就能快速编写出还不错的用例了。 这个法则的教程请见：连接 大概 20 分钟可以读完。
7.搞懂依赖注入和反转控制这两个概念，这是可测性的基础的基础。（Spring 熟手会心的笑了）。链接
8.把你的单元测试加入 CI 流水线。这样它就能更好的被复用了。
9.学会使用 IDE 的快捷键和插件来帮助你生成测试用例框架，这样能够少些很多代码。
10.买本书看吧。推荐 《程序开发人员测试指南 构建高质量的软件》,已经有中文版卖了。另一本书是《Pragmatic Unit Testing in Java 8 》 还木有中文版，不过。。。
11.开始写，不断迭代。不断反馈。
我的建议就这么多。写下你的心得吧。
- 做好单元测试是很重要(我这是废话)
- 我只是觉得，更多的人面临的问题是:
- 新手没有经验，不知道怎么做，摸石头过河，花了时间，很有可能：不要说对公司，实际上自己都没多少收获。更糟糕是认为自己成了战略专家，敲俩代码组个框架就 okey 了，耽误了自己也误导了别人。
- 干了半天搞不出 bug, 恰巧你有个面子工程领导（这能凑出另一篇文儿来）。
- 大多数是小公司。开发自己都不自测（时间紧，懒，或是各种前后端分离，模块分离，搞不清其他模块业务，就知道 入什么出什么，但是入什么好多种情况他也不知道，他也不想知道）。等测试来弄单测么，基本没时间了，还是先测 ui 去吧。
- 有人说，你把这些乱套的流程搞好了，不也是体现你的价值么？
那：
- 你去管，现在的年轻人真是火气大。我在新公司 4 个月，看到了 3 起冲突： 开发和开发 2 次，开发和产品 1 次，好在没动手。
- 全做？ 那你就住公司吧。996 都不够，身体抗的住么（996icu 问题，请问你做过相关回帖么，这又够一篇文儿了）
- 你把自己豁出去了，公司 1 年倒闭了。上市了，没你的份，也不保你养老。运气好利益来了，够分么。
这真是 毒汤太多，其实其他行业也一样恶心, 生活就得禁得住恶心，没有办法的办法, 别气馁
大佬为了装逼 是只能当面说正能量的，除非真是做好后路了。
- 但不管怎么说，做好单元测试是很重要， 我也要去研究研究。其实 我觉得更重要的是不要脱离业务，脱离业务，测试的数据和真实数据差异过大，也起不到效果。当然有人非要说做黑盒去互补，所以这块测试数据无所谓，那我也无话讲。
如果惹到了贴主 请赎罪, 看在我费劲巴力的敲了半天的劲头上
很认同需要先意识到它的价值才能做好。现在开发的代码提测都有强制覆盖率要求了，不过带来的问题就是覆盖率上去了，校验强度因人而异，有些甚至不写 assert 的，看来单测以后也要 review 了
搞懂依赖注入和反转控制这两个概念，这是可测性的基础的基础。（Spring 熟手会心的笑了）。链接
链接打不开
光哥 cheatsheet
刘晓光
回复
你改了 title 没改 content~