作为一个开发人员。很多人很少写单元测试，甚至不写单元测试。

总结一下开发人员不写单测的原因无非有以下几种：

1、认为写单测浪费时间。  2、认为测试不应该是开发人员来做的。  3、自信我写的代码没有问题，不需要单测。  4、不知道单测的重要性。  5、不知道单测的好处。

那么针对以上这几种观点，今天就逐个分析一下。到底单元测试有没有那么重要。

单元测试真的浪费时间吗？

在业务高速发展的今天，很多时候项目来的时候要的都很急。好像要是我不把这个功能在几天之内搞完整个公司都要倒闭了一样。所以，很多开发人员都把主要的时间用在写业务逻辑代码上。很多人都是有时间的时候才会写一些简单的单元测试代码，如果项目比较忙的话就不写单元测试。

很多程序员的项目都是这样完成的：

写代码---->集成测试---->改bug---->集成测试---->预发布测试---->改bug---->正式发布---->发生故障---->改bug---->发布---->改bug---->....

可以看到，改bug过程贯穿着整个软件的生命周期。改bug很多人都知道怎么改，就是要先定位问题，然后再解决问题。往往定位问题都是比较复杂的，一般都需要很长的时间。

如果有了单元测试可能就会节省很多时间，通过单测可以减少很多bug的发生，也能帮助我们快速的定位问题。只要在集成测试之前做好单元测试。在通过单元测试之后，我们就可以认为这部分代码是可靠的，那么就可以放心的进行项目集成。

当然，有了单元测试，并不能保证代码不出现bug。但是，单元测试可以在软件开发过程的早期就能发现问题。只要单测的测试用例足够好，那么就可以避免很多低级错误。

那么，为什么还是很多人认为单元测试浪费时间呢，个人分析原因可能是这样的。开发人员认为我的时间就应该用来写业务逻辑代码。项目出现了bug，我也应该用我的时间来解决这个bug。他们认为我的时间花费在这件事上我是认可的，所以我的时间就不叫浪费。归根结底，他们就是没有意识到单元测试所带来的好处。一旦他们发现，通过单元测试可以让我更早的发现问题等等好处，那么他们也会认可把时间花费在写单测上。

在这里，可以先下一个结论： 好的单测不仅不会浪费时间，还会大大节省我们的时间。 至于为什么会节省时间以及什么叫好的单测会在后面介绍。

单元测试应不应该开发人员来写

这里暂不分析到底应不应该有单独的测试人员，这是一个颇有争议的话题（一部分人认为，开发就应该是全栈的。还有一部分人认为开发就应该只关注业务写业务代码）。这里只分析单元测试到底应该由谁来做。有人认为，单元测试也是测试的一种手段，应该交给专门的QA去做。也有人认为单元测试应该是开发人员来写，那么，单元测试到底应不应该开发人员写呢？

单元测试必须由最熟悉代码的人来写。这是好的单元测试的标准之一。那么还能有谁比写代码的人更了解代码呢？代码的作者最了解代码的目的、特点和实现的局限性。所以，写单元测试没有比作者更适合的人选了。单独的测试人员进行单元测试，往往工作量大，周期长，耗费巨大，其结果事倍功半。软件的开发者总是应当负责程序的单个单元的测试，保证每个单元能够完成设计的功能，其实在很多情况下，开发者也应进行集成测试。

我的观点以为，开发人员写了一个函数，就要对这个函数负责，就有义务保证这个函数可以准确的执行。单测便是一个很好的手段。 所以，如果要写单测，就应该开发人员自己来写。

我很自信，我还需要单测吗？

有人能写出完美无缺的代码么？答案是否定的！

我认为程序员都是天生骄傲的。虽然程序员往往都会说：在我机器上明明是好的呀，是不是你用的方式不对呀。但是，好的程序员应该在说完这句话之后会偷偷的去排查问题。

写代码不是可以一蹴而就的，必须经过各种各样的测试，单元测试只是其中一种。

所以，无论你是一个多么天生骄傲的程序员，你都不是神！所以，你也需要单测。

单测真的有那么重要么？

很多程序员宁愿把时间花费在写业务逻辑代码上，他们多数是有时间的时候才会写一些简单的单元测试代码，如果项目比较忙的话就不写单元测试。据我所知，只有少数的公司会要求项目上线必须达到一定百分比的 代码覆盖率 （软件测试中的一种度量，描述程式中源代码被测试的比例和程度），大多数公司都不是很重视这一项，所有，很多人就不太重视单元测试。但是，很多发生故障的经验告诉我们，很多问题是可以通过单元测试避免的。

其实单元测试的重要性很简单，就是一句话： 不写单元测试，你怎么知道你的代码写的对不对？ 没有足够丰富的测试用例，你怎么知道用户会怎么使用到你的代码，你又怎么会知道你的代码应该怎么被执行呢？

所以，单元测试很重要。和写代码一样重要。无单测，不编码！

单元测试有哪些好处？

前面说了这么多，其实以上这些问题都有一个最最根源的问题，那就是很多程序员不写单测的最最根本原因是他们根本不知道写单测和不写单测的区别。不知道写了单测能带来好处。所以他们会认为写单测是浪费时间，所以他们才会认为单测不应该是由我来写，所以他们才会认为我不需要写单测。

那么，单元测试到底能带来哪些好处呢？

J.Timothy King写过一篇关于先写单元测试有哪些好处的文章： Twelve Benefits of Writing Unit Tests First （先写单元测试的十二个好处），这里挑其中几个显而易见和比较突出的好处介绍一下。

减少bug

单元测试的目的就是通过足够准确的测试用例保证代码逻辑是正确。所以，在单测过程中，必然可以解决一些bug。因为，一旦某条测试用例没有通过，那么我们就会修改被测试的代码来保证能够通过测试。

减少修复bug的成本

一般解决bug的思路都是先通过各种手段定位问题，然后在解决问题。定位问题的时候如果没有单元测试，就只能通过debug的方式一点一点的追踪代码。解决问题的时候更是需要想尽各种方法来重现问题，然后改代码，改了代码之后在集成测试。

因为单元规模较小，复杂性较低，因而发现错误后容易隔离和定位，有利于调试工作。

帮助重构，提高重构的成功率

我相信，对一个程序员来说最痛苦的事就是修改别人的代码。有时候，一个很大的系统会导致很多人不敢改，因为他不知道改了一个地方会不会导致其他地方出错。可以，一旦有了单元测试，开发人员可以很方便的重构代码，只要在重构之后跑一遍单元测试就可以知道是不是把代码“改坏了”

提高开发速度

不写单测也许能让开发速度更快，但是无法保证自己写出来的代码真的可以正确的执行。写单测可以较少很多后期解决bug的时间。也能让我们放心的使用自己写出来的代码。整体提高开发速度。

后记

据我说知，在非死book是没有QA的，他们的所有代码都是通过单元测试来保证能够正确执行的。在google也很重视单测，国外这样的大公司都会要求单测的代码覆盖率达到一个高的水平，否则是绝对不会允许代码发不到线上的。

所以，通过这样一篇文章，希望读者可以重视单元测试，并在实际项目中运用起来。但是，也请记得，单测只能在一定程度上减少bug的发生，并不是写了单测就不会在发生问题。

无单测，不编码！