单元测试系列一-为什么要写单元测试，何时写，写多细

一、前言

半年前在公司团队内推动单元测试的落地，略有一些心得，记录在此。如有不同观点或建议，请在评论区留言，一起探讨。

定义：单元测试是用来对一个模块、一个函数或者一个类来进行正确性检验的测试工作。

单元测试从长期来看，可以提高代码质量，减少维护成本，降低重构难度。但是从短期来看，加大了工作量，对于进度紧张的项目中的开发人员来说，可能会成为不少的负担。

本文从为什么要写单元测试，何时写，写多细这些我们最关心的问题展开讨论，试图解答如何在进度紧张的项目中，通过写有效的单元测试来提高代码质量的问题。

二、单元测试要写多细

酷壳上有篇关于“单元测试要做多细”的文章，文章是从StackOverflow上的一个问题讨论开的。这个问题是–

“TDD需要花时间写测试，而我们一般多少会写一些代码，而第一个测试是测试我的构造函数有没有把这个类的变量都设置对了，这会不会太过分了？
那么，我们写单元测试的这个单元的粒度到底是什么样的？并且，是不是我们的测试测试得多了点？”

点赞最多的答案是–

老板为我的代码付报酬，而不是测试，所以，我对此的价值观是——测试越少越好，少到你对你的代码质量达到了某种自信（我觉得这种的自信标准应该要高于业内的标准，

当然，这种自信也可能是种自大）。如果我的编码生涯中不会犯这种典型的错误（如：在构造函数中设了个错误的值），那我就不会测试它。我倾向于去对那些有意义的错误

做测试，所以，我对一些比较复杂的条件逻辑会异常地小心。当在一个团队中，我会非常小心的测试那些会让团队容易出错的代码。

这个答案给人感觉对单元测试持一定的否定态度