在上周发的一篇
文章
中，我讲到了提高代码质量的几个方法。有读者对其中的单元测试比较感兴趣，今天，我们就聊下：有没有必要写单元测试？有了测试团队，再写单元测试，是否是浪费开发时间呢？
1. 单元测试到底用来测试什么？
以免有读者对单元测试不了解，在讨论这个话题之前，我先简单科普一下，什么是单元测试？
-
单元测试，顾名思义，它测试的是一个小”单元”，这个”单元”一般是类或方法，而不是模块或者系统。
-
单元测试一般都是由开发工程师来完成的，是代码层面的测试，用于测试“自己”编写的代码的正确性。
-
单元测试并不等于测试驱动开发。测试驱动开发是一个理想很丰满，现实不可行的开发思想。而单元测试效果等同于测试驱动开发，但更容易落地执行。
-
单元测试不依赖于任何不可控的组件，如果代码中依赖了其他这些不可控的组件，比如复杂外部系统，复杂模块或类，则需要通过mock的方式，将这些不可控的部分变成可控。
实际上，
写单元测试本身不是一件需要高深技术才能完成的事情，更多的是考验工程师思考的缜密程度
，是否能够设计出完备地覆盖各种正常、异常场景的测试用例，来保证代码在任何预期或非预期的情况下都能正确运行。
2. 写单元测试带来的好处有哪些？
从我个人经验来说，当我们写程序的时候，一般都会侧重正常情况下程序的运行是否符合预期，往往会对异常情况下程序的运行情况，考虑不够全面。
在你写完一个功能代码之后，怎么保证你的代码运行正确？在各种异常（数据异常、输入异常、调用异常等）情况下，程序运行结果都符合你预先设计的预期，返回合适的报错呢？
这个时候，单元测试就派上了用场。
从我个人写单元测试的经验来看，在写单元测试的时候，
几乎每次都会发现很多考虑不全面的地方，都会发现很多”bug“
。设计完备的单元测试用例，非常有助于扫清代码中的各种低级的bug。所以，我一直觉得，提高代码质量，最有效的手段，就是写好单元测试。
Google中有很多项目是完全没有测试团队参与的。代码的正确性完全靠开发团队来保障，线上bug反倒是非常少。
而且，写单元测试的过程本身就是一个自我code review的过程。在这个过程中，你可以发现一些设计上的问题，比如代码设计的不可测试，代码的可读性不好等等。
写单元测试还能增强你对代码的信心。等你写好完备的单元测试，并且代码通过所有的测试用例的时候，你对自己写的代码也会信心大增。这种一切尽在掌握中的感觉是很好的：）如果你好好写过单元测试，那在这一点上，应该能跟我有所共鸣吧。
除此之外，单元测试还对重构代码也有很大帮助。当你发现某个类或者函数实现的不好，你想要重构一下，但又怕考虑不全面，改了之后会出错，出力不讨好，这个时候该怎么办呢？
如果有单元测试情况就不一样了。代码重构完之后，你跑一下原来的单元测试。如果单元测试都通过，那基本上可以保证，你的重构没有破坏正确性。不过，这个的前提是，之前写的单元测试质量很好，覆盖率很高。
3. 为啥很少有公司会写单元测试？
据我了解，国内的互联网公司，包括BAT在内，很少有认真写单元测试的哈，特别是一些开发业务系统的项目组。我个人觉得，这个跟整个公司的技术文化、研发模式都有关系。
很多公司的技术文化，从上到下都没有“代码质量”的意识。写好代码只要能编译通过，并且正常情况下运行符合预期，就直接提交，然后丢给测试团队，狠命的测。测试团队测出问题后，就反馈给开发团队再修改。测不出的问题就留在线上出了问题再解决。
而且，我们很多公司都是996、995，业务驱动，进度催的紧。研发工程师根本就没有时间、精力，来去写单元测试了。因为，一般情况下，
单元测试的代码量往往大于被测代码量，大约会是1-2倍的样子
。
在这样的研发模式以及技术文化下，团队往往觉得单元测试没有必要，浪费时间。
但是，如果我们开发团队，把单元测试写好，做好code review，重视起代码质量来，其实是对项目的一种长期投资。
