【河南软件测试机构：让我们一起聊聊单元测试】

   单元测试是一个伟大的发明。只要团队碰它，几乎很难全身而退。 squaretest   说实话，并没有什么用。根本就没减少我多少的工作量，该覆盖不到的代码，还是覆盖不到。 在IDEA的插件安装界面中，找到squaretest并安装之，你就会拥有这个功能。   中间的话，可能会让你选择一下语言，选择一下模版之类的，这对于一个搞软件的来说并不是难事，所以这里也不再啰嗦。 好家伙，足足给我生成了上万行的test代码。这时候，无论是交给QA看，还是交给分析工具去玩，都能闪瞎它们的眼。 报错不少，还得微调一下参数。但大多数代码已经生成好了，已经节约了很大的力气了。  其他工具 比如JUnitGenerator2.0，连JUnit5都不支持;AgitarOne，虽然只有30天的试用期，但主页也和上古怪兽一样;Randoop的使用，根本就不是为人类设计的;Analytix被google收购后，几乎进入了坟墓。 squaretest，可以说是非常好用了。 你需要单元测试么?  大多数情况下，单元测试不会减少bug，它们会根据bug进行调整，以适应正常代码;另外，如果你的代码都是一些简单的CRUD，写单元测试看不到任何有益的地方。 这个现状，还是要从根源上找原因。 中国式需求，变化奇快，临时需求多，要求快速交付。这些功能，往往复杂性比较低，编写的代码并不会产生过多的bug;由于变化快，编写的单元测试也没有通用的可能性;一次性的代码，写完之后可能永远不再修改，被扔在一个遗忘的角落。 做不到，就不要装。 单元测试从来不是因为写单元测试有多困难，而是大多数代码，是无法写出好的单元测试的。 在TDD(Test-Driven Development，测试驱动开发)模式下，测试的动作比开发早，属于预先设计接口定义的范畴。如果你在后期对接口进行了较多的变更，这种方式同样会让开发人员变的痛苦不堪。  单元测试还阻碍开发人员重构的动力。因为重构意味着要动很多的测试代码，往往很多人偷偷一评估，就放弃了。   让人欣慰的是，追求原则的团队还是有的，正确的方式可以避免很多曲折的路线，抛掉技术债所造成的负面影响。能够加入这些团队，是非常幸福的事情。 作为非技术管理人员，当有人为你提出类似这种耗费工期的，长远有益的建议，不要着急否定。看一看其他优秀的企业，是不是也曾因这些短暂的原地踏步而受益过。无知并不可怕，可怕的是不相信专业。如果你肯定了，给予支持，而不要半途而废。有意思的是，半途而废最终并不会废止，它同样会蜕变为形式主义，将一件美好的事情硬生生变成指标。 单元测试代码是无聊的、枯燥的，尤其是为别人写的代码补充单元测试。通常情况下，如果不发生bug，没有人会闲的去动，除非是不自量力的小牛犊。 这个时候，一个得心应手的工具，自动帮你完成工作，让你的单元测试代码拥有生命周期，不得不说是一件快事。