如果是我们自己写的代码，那么，写写单元测试也无伤大雅。但我们绝大多数人，都是跟在别人后面打扫狗屎，或者是留给别人一堆狗屎。这时候，单元测试写起来，就有一种不情不愿的味道。
没错，就是不想写!文章源自玩技e族-https://www.playezu.com/193503.html
为了应付所谓的指标，我们要给那些遗留代码，将要发臭的代码上一剂良药：那就是自动化。假如这些糟心的代码，大部分交给机器去写，我想很多人是非常乐意的。文章源自玩技e族-https://www.playezu.com/193503.html
squaretest
有很多这样的工具，比如IDEA自带的。但是它只能生成一些表面功夫的东西，也就是生成一个骨架而已。文章源自玩技e族-https://www.playezu.com/193503.html
说实话，并没有什么鸟用。根本就没减少我多少的工作量，该覆盖不到的代码，还是覆盖不到。文章源自玩技e族-https://www.playezu.com/193503.html
这个时候，我们需要更高级一点的工具。经过测试，现在瞄准了squaretest。文章源自玩技e族-https://www.playezu.com/193503.html
在IDEA的插件安装界面中，找到squaretest并安装之，你就会拥有这个功能。文章源自玩技e族-https://www.playezu.com/193503.html
重启IDEA之后，从你的屎山中，找到最臭的那一块，然后就可以在菜单中找到这个工具，生成代码。文章源自玩技e族-https://www.playezu.com/193503.html
中间的话，可能会让你选择一下语言，选择一下模版之类的，这对于一个搞软件的来说并不是难事，所以这里也不再啰嗦。文章源自玩技e族-https://www.playezu.com/193503.html
好家伙，足足给我生成了上万行的test代码。这时候，无论是交给QA看，还是交给分析工具去玩，都能闪瞎它们的狗眼。
hehehehehehe....漂亮!
报错不少，还得微调一下参数。但大多数代码已经生成好了，已经节约了很大的力气了。
其他工具
这貌似不是一个好的赛道。因为很多工具都不怎么维护了，或者不怎么好用。用爱发电越来越行不通了。
比如JUnitGenerator2.0，连JUnit5都不支持;AgitarOne，虽然只有30天的试用期，但主页也和上古怪兽一样;Randoop的使用，根本就不是为人类设计的;Analytix被google收购后，几乎进入了坟墓。
squaretest，可以说是非常好用了。
你需要单元测试么?
很多人没得选，因为这是硬指标。如果你的工作流程有问题，单元测试不但不能增彩，反而会成为累赘。
大多数情况下，单元测试不会减少bug，它们会根据bug进行调整，以适应正常代码;另外，如果你的代码都是一些简单的CRUD，写单元测试看不到任何有益的地方。
这个现状，还是要从根源上找原因。
中国式需求，变化奇快，临时需求多，要求快速交付。这些功能，往往复杂性比较低，编写的代码并不会产生过多的bug;由于变化快，编写的单元测试也没有通用的可能性;一次性的代码，写完之后可能永远不再修改，被扔在一个遗忘的角落。
要写单元测试，你要确保你的单元测试多年之后还可以用。而不是等到项目尾声，为了达到指标而集中补充单元测试。单元测试要想发挥它的价值，需要在一开始就创建相关的代码，扪心自问，很多团队是做不到这一点的。
做不到，就不要装。
单元测试并不简单
有意思的是，即使环境达到了要求，所有的接口都提前设计了，且保持较少的变动，我们依然无法推行单元测试。
单元测试从来不是因为写单元测试有多困难，而是大多数代码，是无法写出好的单元测试的。
在TDD(Test-Driven Development，测试驱动开发)模式下，测试的动作比开发早，属于预先设计接口定义的范畴。如果你在后期对接口进行了较多的变更，这种方式同样会让开发人员变的痛苦不堪。
单元测试需要配合极限编程，经常对代码进行重构。这是设计腐化之后的一种补救式措施。但很多情况下，大家都害怕、拒绝对旧代码进行修改。工期和稳定性是常见的借口，这些借口看起来比扩展性和可测试性看起来更正常一些，也更能说服高层进行决策。
没有几个技术决策者，能够在销售、产品、老板的重重压力下保持初心，做这种长远性的规划。所以说单元测试肯定是有用的，但却缺乏实施的土壤。按时上线、提前上线、bug数量，这些常见的指标，只反映了结果，那些去改进这些结果的措施，短期效应不是很明显的话，很容易就胎死腹中。
单元测试还阻碍开发人员重构的动力。因为重构意味着要动很多的测试代码，往往很多人偷偷一评估，就放弃了。
坚持对的事情
选择一个优秀的团队，是非常重要的。大家都很专业，不会亏待你所信仰的正确。专业的人才在二流子团队中，会像一个小丑一样无助，大多数习以为常的经验，几乎无法实施。
让人欣慰的是，追求原则的团队还是有的，正确的方式可以避免很多曲折的路线，抛掉技术债所造成的负面影响。能够加入这些团队，是非常幸福的事情。
作为程序员，应该时刻保持这种好的习惯，不要因为赶工，忽略了代码的重构和测试。这些是一个专业的技术人员应有的素质，而不是寄希望于公司的大环境中。这些好的习惯，就像人的气质一样让人着迷，最终会让你超脱于其他人而受益。
作为技术管理者，你要正确评估自己的公司环境，是不是具有单元测试的生长土壤。即使你明白单元测试是有益的，你也不得不做一些取舍。尤其是你判断项目只不过是你的垫脚石，3年之后肯定不会在自己的手里，你更会任由它自我腐烂掉。如此情况，大家都心知肚明，没人会对你说三道四。
作为非技术管理人员，当有人为你提出类似这种耗费工期的，长远有益的建议，不要着急否定。看一看其他优秀的企业，是不是也曾因这些短暂的原地踏步而受益过。无知并不可怕，可怕的是不相信专业。如果你肯定了，给予支持，而不要半途而废。有意思的是，半途而废最终并不会废止，它同样会蜕变为形式主义，将一件美好的事情硬生生变成指标。
End
单元测试代码是无聊的、枯燥的，尤其是为别人写的代码补充单元测试。通常情况下，如果不发生bug，没有人会闲的蛋疼去动那一堆堆的屎山，除非是不自量力的小牛犊。
这个时候，一个得心应手的工具，自动帮你完成这些操蛋的工作，让你的单元测试代码拥有和屎山一样的生命周期，不得不说是一件快事。
作者简介：小姐姐味道 (xjjdog)，一个不允许程序员走弯路的公众号。聚焦基础架构和Linux。十年架构，日百亿流量，与你探讨高并发世界，给你不一样的味道。我的个人微信xjjdog0，欢迎添加好友，进一步交流。