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

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


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

  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,没有人会闲的蛋疼去动那一堆堆的屎山,除非是不自量力的小牛犊。

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

文章目录
  1. 1. squaretest
  2. 2. 其他工具
  3. 3. 你需要单元测试么?
  4. 4. 单元测试并不简单
  5. 5. 坚持对的事情
  6. 6. End