无单测、不编码——写单元测试的重要性

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

单测真的有那么重要么？

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

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