为什么要进行单元测试？

单元测试是保证软件质量的一个很好的手段。开发团队如果能够顶住项目进度的压力，认真的在项目执行过程中进行高质量的单元测试活动，对软件产品是有很大裨益的；花费在单元测试上的时间和资源，相较于代码稳定性的提高，绝对是值得的。

直接的来看，单元测试可以验证代码质量，这是其最基本而不言而喻的作用。对代码的测试可以尽早发现错误并进行修正；成功的测试就意味着代码执行结果符合我们的预期。这也是大多数团队能够达到的共识。但是，单元测试不是保证代码质量的唯一方法，有时候我们会觉得认真的写代码、审查和调试就足够保证代码的正确性了，不需要多此一举的写一些test case，把时间浪费在肯定会测试通过的单元测试上。

在某一次代码编写过程中，情况可能确实是这样。有经验的程序员会有足够的能力控制他们的代码。但是，单元测试的价值还在于，在整个软件开发过程中，它都可以验证代码质量。

即便我们是工作在瀑布法的开发框架下，我们都不能信心满满的保证写出的代码和模块再不进行改动。需求变更是每个开发团队都必须面对的风险，而软件开发本身就是一个不断迭代和演进的过程，变化贯穿于始终。单元测试的价值不仅仅在于当我们编写代码时能够验证代码的有效性，更重要的是，在我们两周或者三个月以后修改和重构代码时，它依然可以作为代码有效性的标杆。我们可以自信的说能够写出一个无错的函数，但谁能自豪的说，即使在半年后，我们也能够修改这个函数而不引入新的错误？

单元测试用例在软件项目中，就是函数的契约。当然，设计文档也是函数的契约，但是设计文档是无法直接用作函数的测试标准的，没有工具能够在设计有效性和代码有效性间直接映射。当在面对函数的修改和演进时，单元测试用例就是最直接和最有力的验收工具。

单元测试的另外一个不那么直接，但是更重要的作用是能够帮助程序员提高设计。编写单元测试用例的目的，是对设计文档（假如这个文档存在的话）或需求的一次翻译。和编写代码不同的是，设计代码时我们主要在想“怎么做”，而设计用例时我们会想“做什么”。编写测试用例会促使我们更好的思考要完成什么样的功能，达到什么样的目的。编写测试用例是一个“以终为始”的活动，是对需求的理解，并引导代码设计以需求为唯一目标。

单元测试能够帮助提高设计也表现在编写用例这一过程中。用例的测试结果会帮助我们找到代码中的bug，而编写用例的过程，则会帮助我们反思代码的设计和逻辑是否恰当。如前所述，编写测试用例是对需求的一次翻译，也是将需求描述为程序语言的过程，在这个以“做什么”为重心的代码编写过程中，我们会发现目标代码逻辑中的不足和繁复，同时，对目标代码的改进也会促使对测试用例的反思，在两者相互迭代的过程中，代码的结构和需求的要求能够能好的贴合起来。

单元测试能够在代码编写和设计演进时验证代码质量，同时也能够促进设计的提高。但单元测试是一种构建性的活动，团队往往只注意到其需要的额外的资源，而不能直观的看到其效果，在开发过程中也常常因为资源和进度的压力而被忽略。然而正如质量大师克劳士比所说，第一次就要把事情做对，单元测试是能够辅助我们第一次就做对事情的方法，付出者必然得到回报。