本文是对 Parasoft CEO 也即 《 自动缺陷预防：软件管理中的最优实践 》（Wiley-IEEE,2007）一书的共同作者 Adam Kolawa 系列采访的一部分，在这个部分中，Adam 论述了何时，为何以及如何引入基础软件验证。同时，这个部分还谈到了静态代码分析、代码走查、内存错误检测、消息/协议测试、功能测试以及负荷测试等。

　　在本访谈中，Kolawa 驳斥了单元测试即将淘汰的说法，解释了单元测试是如何为用户在“早期测试”中实现价值的，并且指出代码覆盖率并不是评估测试套件完整性的最佳方法。通读本文能帮助读者明确如何迅速可靠地修改代码，以及如何方便地开始。

　　目前，单元测试在理论界是一个热门，而在实际使用中却是少有问津。请问你对此有什么看法呢？

　　单元测试需要设置实际且有效的测试套件，这是相当复杂的。开发者往往对应用程序的外部表现很清楚，比如应用程序将怎样响应用户的操作等，但是对应用程序内部本身的运作情况却知之甚少。而这对编写单元测试套件而言确实是相当关键的。当使用单元测试时，开发者需要创建相应的初始化条件，这能使得应用程序像一个完整的系统那样工作。如果初始化条件设置不正确，那么单元测试的结果将不能反映程序在实际中的运行情况，这样的结果对开发者而言也不会非常有用。除非能模拟程序运行的真实情况，否则你不能确保某些模块正确无误。这一点是相当关键的。比如，某个模块可能要求支持很多条件…但当你在创建它的时候，你就需要知道其相应代码是否能够维持该要求。除非你能在相应的环境中进行验证，否则你不能确保这些模块的正确性。

　　创建初始化条件是相当困难的，但又是绝对必须的。我认为试图严格地创建初始化条件的开发者可能会为其所需的工作量而感到气馁，相反，其他的开发者可能会为单元测试报告的无价值的结果而感到失望。

　　现在关于单元测试是否有存在的必要性有很多的争论。你怎么看呢？

　　我认为单元测试在现在比以往任何时候都更加有用。但我认为我们应该有较人们普遍关注的单元测试所不同的测试，也即早期测试。下面解释一下。

　　今天我们所构建的系统，如 SOA 及 RIA 等，无论从大小还是复杂度上都是以往所不能同日而语的，再加上较以前更短的开发周期。一般而言，我们对哪些功能需要测试都有一个清楚的了解，因为在需求中对测试用例已经有了很好的定义。尽管如此，由于其复杂性，例如很多系统往往与外部世界相连，分期系统难以建立和维护，每次测试均需要大量的设置等等诸多困难，所以作为整体测试的时候仍然是很困难的。也许对每个用例测试一次是可行的，但是你必须得进行日常的测试以保证破坏性的修改能够被即时发现。

　　这也是单元测试的产生原因吧？

　　是的。单元测试在帮助开发者测试模块的同时省去了处理复杂系统的烦恼。使用类似Parasoft Tracer 的技术，开发者可以创建单元测试用例来捕捉其中的功能。使用应用程序的图形用户界面（GUI），SOA 或者网络测试客户端，开发者只需要在打开 Tracer 功能的时候运行测试用例。在测试用例执行的同时，Tracer 能够监视所有被创建的对象以及输入输出数据，随后为开发者创建一个能模拟这些操作的单元测试套件甚至设置好相应初始化条件。

　　这些生成的单元测试套件可以在其它机器上独立使用。这就意味着开发者可以只使用一台机器，甚至是一个标准桌面开发环境，以在验证过程中复制一个复杂系统的行为。将这些测试套件加入到回归测试套件中，并且持续地运行能使开发者迅速地发现代码的修改是否影响了功能。

　　根本地讲，这能从两个方面解决今天的复杂系统中包含的问题：

　　1. 帮助开发者设置耗时且繁琐的实际测试条件。

　　2. 帮助开发者创建能独立运行的持续性全自动测试用例。