阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 小姐姐味道 「小姐姐养的狗」欢迎转载，保留摘要，谢谢！

• squaretest
• 其他工具
• 你需要单元测试么？
• 单元测试并不简单
• 坚持对的事情
• End

---

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

单元测试是一个伟大的发明，同时也是一个操蛋的发明。只要团队碰它，几乎很难全身而退。

如果是我们自己写的代码，那么，写写单元测试也无伤大雅。但我们绝大多数人，都是跟在别人后面打扫狗屎，或者是留给别人一堆狗屎。这时候，单元测试写起来，就有一种不情不愿的味道。

没错，就是不想写！

为了应付所谓的指标，我们要给那些遗留代码，将要发臭的代码上一剂良药：那就是自动化。假如这些糟心的代码，大部分交给机器去写，我想很多人是非常乐意的。

squaretest

有很多这样的工具，比如IDEA自带的。但是它只能生成一些表面功夫的东西，也就是生成一个骨架而已。

说实话，并没有什么鸟用。根本就没减少我多少的工作量，该覆盖不到的代码，还是覆盖不到。

这个时候，我们需要更高级一点的工具。经过测试，现在瞄准了squaretest。

在IDEA的插件安装界面中，找到squaretest并安装之，你就会拥有这个功能。

重启IDEA之后，从你的屎山中，找到最臭的那一块，然后就可以在菜单中找到这个工具，生成代码。

中间的话，可能会让你选择一下语言，选择一下模版之类的，这对于一个搞软件的来说并不是难事，所以这里也不再啰嗦。

好家伙，足足给我生成了上万行的test代码。这时候，无论是交给QA看，还是交给分析工具去玩，都能闪瞎它们的狗眼。

hehehehehehe....漂亮！

报错不少，还得微调一下参数。但大多数代码已经生成好了，已经节约了很大的力气了。

其他工具

这貌似不是一个好的赛道。因为很多工具都不怎么维护了，或者不怎么好用。用爱发电越来越行不通了。

比如JUnitGenerator2.0，连JUnit5都不支持；AgitarOne，虽然只有30天的试用期，但主页也和上古怪兽一样；Randoop的使用，根本就不是为人类设计的；Analytix被google收购后，几乎进入了坟墓。

squaretest，可以说是非常好用了。

你需要单元测试么？

很多人没得选，因为这是硬指标。如果你的工作流程有问题，单元测试不但不能增彩，反而会成为累赘。

大多数情况下，单元测试不会减少bug，它们会根据bug进行调整，以适应正常代码；另外，如果你的代码都是一些简单的CRUD，写单元测试看不到任何有益的地方。

这个现状，还是要从根源上找原因。

中国式需求，变化奇快，临时需求多，要求快速交付。这些功能，往往复杂性比较低，编写的代码并不会产生过多的bug；由于变化快，编写的单元测试也没有通用的可能性；一次性的代码，写完之后可能永远不再修改，被扔在一个遗忘的角落。

要写单元测试，你要确保你的单元测试多年之后还可以用。而不是等到项目尾声，为了达到指标而集中补充单元测试。单元测试要想发挥它的价值，需要在一开始就创建相关的代码，扪心自问，很多团队是做不到这一点的。

做不到，就不要装。

单元测试并不简单

有意思的是，即使环境达到了要求，所有的接口都提前设计了，且保持较少的变动，我们依然无法推行单元测试。

单元测试从来不是因为写单元测试有多困难，而是大多数代码，是无法写出好的单元测试的。

在TDD(Test-Driven Development，测试驱动开发)模式下，测试的动作比开发早，属于预先设计接口定义的范畴。如果你在后期对接口进行了较多的变更，这种方式同样会让开发人员变的痛苦不堪。

单元测试需要配合极限编程，经常对代码进行重构。这是设计腐化之后的一种补救式措施。但很多情况下，大家都害怕、拒绝对旧代码进行修改。工期和稳定性是常见的借口，这些借口看起来比扩展性和可测试性看起来更正常一些，也更能说服高层进行决策。

没有几个技术决策者，能够在销售、产品、老板的重重压力下保持初心，做这种长远性的规划。所以说单元测试肯定是有用的，但却缺乏实施的土壤。按时上线、提前上线、bug数量，这些常见的指标，只反映了结果，那些去改进这些结果的措施，短期效应不是很明显的话，很容易就胎死腹中。

单元测试还阻碍开发人员重构的动力。因为重构意味着要动很多的测试代码，往往很多人偷偷一评估，就放弃了。

坚持对的事情

选择一个优秀的团队，是非常重要的。大家都很专业，不会亏待你所信仰的正确。专业的人才在二流子团队中，会像一个小丑一样无助，大多数习以为常的经验，几乎无法实施。

让人欣慰的是，追求原则的团队还是有的，正确的方式可以避免很多曲折的路线，抛掉技术债所造成的负面影响。能够加入这些团队，是非常幸福的事情。

作为程序员，应该时刻保持这种好的习惯，不要因为赶工，忽略了代码的重构和测试。这些是一个专业的技术人员应有的素质，而不是寄希望于公司的大环境中。这些好的习惯，就像人的气质一样让人着迷，最终会让你超脱于其他人而受益。

作为技术管理者，你要正确评估自己的公司环境，是不是具有单元测试的生长土壤。即使你明白单元测试是有益的，你也不得不做一些取舍。尤其是你判断项目只不过是你的垫脚石，3年之后肯定不会在自己的手里，你更会任由它自我腐烂掉。如此情况，大家都心知肚明，没人会对你说三道四。

作为非技术管理人员，当有人为你提出类似这种耗费工期的，长远有益的建议，不要着急否定。看一看其他优秀的企业，是不是也曾因这些短暂的原地踏步而受益过。无知并不可怕，可怕的是不相信专业。如果你肯定了，给予支持，而不要半途而废。有意思的是，半途而废最终并不会废止，它同样会蜕变为形式主义，将一件美好的事情硬生生变成指标。

End

单元测试代码是无聊的、枯燥的，尤其是为别人写的代码补充单元测试。通常情况下，如果不发生bug，没有人会闲的蛋疼去动那一堆堆的屎山，除非是不自量力的小牛犊。

这个时候，一个得心应手的工具，自动帮你完成这些操蛋的工作，让你的单元测试代码拥有和屎山一样的生命周期，不得不说是一件快事。