编写单元测试的10个Reason

大部分程序猿(媛)都不会对自己的代码编写单元测试，原因无非是：

• “我不知道如何去编写测试代码…”
  

• “编写测试代码对我来说太难了！”
  

• “我可没时间做这个！”
  

• “测试可不是我的工作哦~”
  

• “我的程序很简单，不需要进行单元测试吧…”

殊不知，编写单元测试是提高软件质量的非常有效的武器，毕竟对于我们编写的代码来说，只有自己才是最了解并且最知道哪里可能出现问题的人。

• Tests Reduce Bugs in New Features

为你的新功能添加单元测试将会提高代码的质量。单元测试不可能消灭bug，但是可以在你添加新功能时明显减少bug数量。

• Tests Reduce Bugs in Existing Features

通过良好的单元测试，可以很好避免新代码对已有功能的影响。如果添加新代码使已有功能出现问题，现有的单元测试case会立刻失效，你将很容易发现出现bug的位置。

• Tests Are Good Documentation

随着时间的流逝，你会对以前编写过的一些接口、类、方法等的功能变得模糊不清，这时候单元测试代码就是你回忆起这些功能的最简洁易懂的代码片段了，远比注释实用的多。

• Tests Reduce the Cost of Change

单元测试会让你更大胆地尝试新想法对程序进行修改而不需要考虑对已有功能的影响，如果出现问题的话也能够及时准确地定位，这无疑会大大减少修改已有代码产生bug后再Debug的成本。

• Tests Improve Design

单元测试强迫你编写“可测试”的代码。这样，你就会越来越少的依赖单例和全局变量，相反的，使你所编写的类耦合性更小，更方便使用，因为耦合性较大的代码是很难测试的哦！

• Tests Allow Refactoring

单元测试会让你更便于对代码进行重构。你不必去考虑重构对已有功能的影响，有了单元测试的支撑，即使出现bug，也会很容易定位。

• Tests Constrain Feature

很多时候，程序员编写的代码并不能完全满足客户的需求，这时你可以采用“测试优先”的策略，即首先为你将要实现的每个功能编写一些单元测试用例，再去实现功能。这样，当每个功能的用例pass的时候，就可以继续去开发下一个功能了。这样的应用是很易于扩展的。

• Tests Defend Against Other Programmers

这是在实际工作中很容易出现的问题，举个例子，假如你编写了一段在“特定条件”下才会执行的代码，另外一个程序员修改了这段代码，但由于没有达到“特定条件”，程序没有执行，他并不知道可能产生的bug。这时，有单元测试做保障的话，如果出现问题，相应的case就会失败，并及时通知你问题所在。

• Testing Forces You to Slow Down and Think

当添加新功能或对已有代码进行重构时，事先编写好的单元测试会迫使你停下来思考正在编写的代码是否会达到预期结果，这样你就会更注意提高代码质量，而不是一味的追求完成任务了。

• Testing Makes Development Faster

如果有良好的单元测试做保障，你可以在最初的开发中只保证你所负责的一些接口的功能正确性，而不需要刻意关注这些接口的内部实现细节，这样会大大提高最初实现功能时的效率。而且在后续的维护和接口内部算法优化时，也不用害怕破坏整个接口的功能，单元测试会帮助你发现并解决问题。

原文链接

如需转载该篇文章，请注明来自“搜狗测试”