如果实施得当，单元测试可以帮助开发团队更快地交付应用程序，换言之，它能够提高企业的竞争力。然而，只有很少的企业尝试过使用单元测试，而其中有只有一小部分成功地将其作为标准在企业范围内推广。为什么会这样？通常，这是由软件开发人员和管理人员对单元测试的作用，以及维持单元测试所需付出代价的错误认识所造成的。

以下就阻碍软件开发团队从单元测试这一强大的软件验证方法中受益的五个最常见的错误认识：

错误1：我们已经在做单元测试

每个人对“单元测试”都有不同的认识，不过大多数业界专家普遍认为，单元测试应该是测试应用程序的基础组成部分，即代码单元。换句话说，这是API层次上的测试。一些团队声称他们在做单元测试，而实际上他们做的是系统测试，或者是所谓的“开发测试（dev test）”。还有一些团队做了部分API层次的测试，但他们并没有把单元测试作为开发过程中的必要组成部分。

除非团队把持续进行API层次的单元测试作为开发过程中不可缺少的组成部分，否则单元测试必然会随着日程与预算带来压力的提升、政策与项目的发展，以及人员的流动而灭亡。

那些极少数长期保持傲人业绩的企业正是把单元测试安排为例行任务的企业。因此，不但要利用自动化测试来保证单元测试尽量全面、顺畅、高效地执行，还要为保证这一质量过程能够长期执行并根据需求而调整来确定基本的工作规范，比如把各个报告中的问题直接指向负责的开发人员，以及让管理人员能够及时方便地看到各开发人员的测试任务分配情况等。

错误2：自动测试并没多大用处

许多开发人员认为，除非是亲自编写单元测试，否则其一点利用价值都没有。这就大错特错了。由于生成测试的方式与算法的发展，测试工具也变得越来越有效。即使是最基本的自动化方法，也可以在很短时间里生成几千个原来根本无法完成的测试。这可是毫不费力就可以得到的好处。

除了可以给你生成测试，甚至“免费”帮你找到一些缺陷，自动测试还能让你集中精力进行那些更重要、更复杂、更全面的测试，那些真正需要专业技术的测试。

当前工具所能提供的高层次的自动测试能够显著减少开发团队在这些方面的工作，从而节省大量的时间与精力。如果没有这些工具的帮助，单元测试可能会消耗团队的大量资源，而这正是让许多团队认为单元测试是一种理论上有用但实际却很难实行的测试方法的原因所在。

错误3：要做的只是购买一个优秀的单元测试工具

我见过许多团队在购买测试工具时把它当做实现目标或完成任务的万能药。他们不想在其上花费任何精力，不对其进行任何设置，也不将其作为工作日程的一部分。到最后，他们自然也无法得到理想的结果。他们以为单元测试没有给他们带来任何好处，而实际上他们并没有执行真正意义上的单元测试——而只是在空谈。

单元测试工具并不是可以解决所有问题的王牌。事实上，它只是一个开始。开发人员需要的不仅仅是工具，他们还需要适当的指导、训练、支持设施和工作流程。如果真的希望这个工具能够成为开发过程的一部分，你就得积极主动地学习和使用它，寻找让它能在既定工作环境下发挥作用的办法，并保证这些使用方法都简单易行。目前有许多可以使用的工具，但是除非测试团队真正去使用它——部署、扩展并根据情况进行调整，否则你买到的只是“闲置工具”而已。

错误4：自动测试达到75%的覆盖率——任务完成！

许多人认为，如果自动测试工具能够生成近75%覆盖率的测试，他就能跟老板说自动测试已经完成了。这绝对是个错误的想法。虽然这是一个非常好的开始，但你不能仅仅因为这一点就认为已经做完单元测试。实际上你只是刚刚开始而已，你还需要验证软件的具体功能。

自动测试很有用，但必须让这些测试与需求挂钩。为了实现这一点，你可以检验并了解这些工具给你生成的测试，然后利用这些免费“礼物”去实现更多的价值。

大多数自动测试工具都会提供一些工具集，使你能够扩展这些自动生成的测试。比如Parasoft Jtest里就有对象库、桩、测试用例参数化和追踪工具Tracer（一个只需在应用程序中运行用例便可以生成功能测试用例的工具）。

错误5：单元测试不值得费工夫

每个了解单元测试的人都知道，这绝不是一份简单的工作，但这并不意味着不值得在这方面花费工夫。

单元测试确实有很高的门槛：测试团队必须了解什么是单元测试、怎样进行单元测试、用它测试什么，以及如何使用工具简化单元测试。如果测试团队真的对单元测试不感兴趣、不了解，甚至根本没有时间开始尝试它，那么他们可能就不会感觉到单元测试的紧迫性。有些团队可能认识到单元测试的重要性，但他们只是被问题缠得团团转，而没有花时间在真正的方向上迈出第一步。归根到底，这需要对单元测试的价值、对质量方面的责任，以及它将为项目争取到的额外时间有一个清楚的认识。

那么，是什么让单元测试的价值超过为此付出的努力呢？单元测试的一个很大优势在于，发现问题的时间越早，在后期遇到的深层错误就越少。这里说的深层错误是指那些并没有形成真正破坏，但它们在API里隐藏得越来越深，直到最后诱发真正问题的错误。这种情况发生的时候，通常很难发现问题的源头。即使你找到源头，也会发现已经有太多的代码层依赖于这个API。

如果正确地进行单元测试，验证代码能够准确地实现功能，就能更早、更有效地发现问题。如果能及早发现问题，缺陷就不会被带入源代码库中，也就是说以后也无需再对它进行修改——通常这时再修改的困难度、成本与时间都会指数叠加。

从我的经验来看，那些真正采用单元测试的开发人员最终都能写出更为优秀的代码，工作效率自然也更高。而原因则在于他们不会被各种缺陷绕得团团转，无须一次又一次地重写同一段代码。任何接受了单元测试，并将其作为所有开发项目标准来实践的企业都能显著地提高质量，减少软件开发过程中的缺陷，并最终获得巨大的竞争优势。