【IT168 技术文章】

　　开始编码的时候没有人告诉你什么是测试。很大的一个问题摆在我们面前，如何验证自己编码的正确性。当然，你可以把这些问题留给系统的使用过程之中，但那个时候发现真正的代码中存在的问题，就变得非常困难，而这时代码中一旦存在大量的耦合性，真正修正一个问题，就变得更为困难。于是，我们需要在更早的时候发现问题，同时我们需要把一个耦合的复杂问题转化为多个简单的内聚单元，由是单元测试随之产生。

　　传统的软件工程中把单元测试放在编码之后，而单元测试的执行人通常就是程序员本人，这个时候程序员依赖自己的预期对分解了的程序单元模块（通常是一个函数或者方法），按照一定顺序执行自己的期望测试，通过执行一个驱动模块，调用程序中的桩模快，得到一个预期结果，比较预期结果和期望结果，如果一致那么测试通过，否则通过代码走读或者逐行调试，发现隐藏在代码中的问题，最终使预期结果和期望结果保持一致。

　　大型软件开发和中小型软件开发的差异，在软件开发过程和软件开发方法中国外的一些知名程序员开始对单元测试的理念进行改进。软件工学本身就是一个自醒、改进的体系。随着新兴敏捷和xp理念的引入，Test driver development(TDD)已经成为一个单元测试的另一种理念。和传统理念的差异是TDD把单元测试放在了代码功能模块之前，前置测试的引入，使我们将OO令人敬畏的理解变成面包和水，我们引入Mock Object ，而这正好是在我们尚未用代码构建我们的系统之前。这样的好处显而易见，测试代码独立于开发的代码单独存在，每个测试代码都有一个目的，在TDD的测试工具中Xunit独树一帜，尤其是经典的Junit，断言的引入，使我们明白每个程序单元究竟要完成怎样的目的。如果写单元测试用例的人和写被测单元的人是同一个，前置测试，使他在编码以前就明白自己每块程序的目标，而且所有的目标都建立相应的成功标准。开发的时候他就会更准确的实现这些目标，在完成开发代码之后，执行那些独立的单元测试，我们很容易看到结果，由于断言的引入，假设每个断言确实反映了每个函数的目标，发现断言失败之后，我们需要小心的检查代码，找出那些造成断言失真的问题。这样作的另外一个好处，就是促成了单元测试的自动化，而这正是我们不再想看那些令人眼花屏显输出时的最好解决方法。而假设单元测试的编写者和编码者不是同一个人，似乎我们又找到了一种良好的监督机制，最终的结果就是让那个被监督的人完成应有的测试目标。