传统的单元测试和面向对象的单元测试

传统的单元测试和面向对象的单元测试
在过去使用编写面向过程方式编写程序时，人们依然运用自己的智慧总结出代码复用的的方法。通常程序员会把实现相同功能的代码放在一起，做成一个函数；将一个或几个逻辑功能独立并且相似或相关的函数组织在一个文件当中。当客户程序需要使用已经定义的函数时，只要将需要的文件include进来就可以了。这是通常的做法。
在做这样的单元测试时我们只要编写一段客户代码，然后调用相关文件中的函数。通过定义不同的前置条件，就可以验证每个单元是否符合他的说明要求。如果通过了单元测试，却在集成的时候出现问题，大多数情况下是接口实现出现了错误，测试的重点往往集中在集成测试而不是单元内部实现的测试。
现在，绝大多数的软件组织都选用了C++，Java, VB（尽管VB的面向对象性不是很好，但还是可以算在面向对象程序语言范畴之内）等面向对象的程序语言来进行开发。面向对象思想的引入，改变了过去的编程习惯。我们不再用“文件”这种硬概念来组织逻辑代码，而是开始使用“类”这种软概念。类逐渐成为独立功能代码片断的集合体，也就成了面向对象程序的基本单位。设计良好的类是功能代码的良好集成。因此，现代的单元测试逐渐演化成为对类的测试。
类测试与传统单元测试相比较有很多不同的地方，这些不同源于面向对象与面向过程的不同。一个类可以有一个或者很多个实例。而且在一定条件下，实例与实例之间可以相互作用，相互通讯。这种复杂性增加了类测试的难度。对于一些简单的类，我们可以使用类似传统单元测试的方法，但是高级的类就要求测试人员对系统的整个体系有一个比较完整的认识，只有这样，构造出来的测试环境才能够适应被测试的类。对于一些比较复杂的对象作用，编写测试环境代码有时候非常困难。对于测试人员来说，完成测试环境需要的开发时间甚至远远超过程序实现的时间。这个时候我们必须要么对程序设计进行修改，要么放弃针对这个类的测试。
测试人员的工作就是要证明开发人员的代码是否符合要求，要完成这一点在必要的时候要构建测试容器。但是构建测试容器是需要成本的，而这一点往往是管理人员经常忽略的。