迷思1：单元测试使得更改变得更加困难
事实却是相反的。进行单元测试的最大优点之一就是能够对代码进行大型修改，然后立即对所做更改进行正确性测试。进行代码修改，后来蔡意识到软件的其他部分受到了影响，接下来试图隔离出引起问题的代码，这不单单使得代码的更改更加困难，也让开发人员恐惧更改代码。
事实是：单元测试使得代码更改更加容易，而且也让开发人员毫无顾虑地修改代码。一遍，两遍等等。能对代码修改是人们选择进行单元测试的最大的理由之一。
迷思2 :单元测试减慢了开发过程
进行单元测试一开始会让开发过程慢一点，然而事实是这么做反而节省了时间：它在开发过程继续进行之前就防止了错误，并识别出错误出现的地方。而 且 单元测试也使得开发人员对自己已经完成的工作更加有信心，这样就会扫清开发过程中出现的障碍。纵观整个开发过程，进行单元测试最终会使得总体花费时间 会更 短。
事实是：像任何一种新工具一样，习惯进行单元测试也需要一点时间，不过，总的来说，进行单元测试可以节省时间，同时浪费的时间也会缩短。实际 上， 进行回归测试可以持续不断地推进开发过程，并且不会有任何担心。假若在日常构建时进行单元测试，那么这样的测试是不会占用开发时间的。
迷思3：单元测试让开发人员远离代码
这是很显然的误解。正是开发人员才能帮助设计测试程序。这就意味着开发人员需要更加深入的了解代码功能，而且要对整个程序中的更小单元的功能负更多地责任。在我们查看整个程序的时候，有时候很容易忽视函数和过程，然而，有了单元测试，我们就不会对函数和过程视而不见了。
事实是：与其他方法相比，单元测试要求开发人员不仅仅要看得懂代码和代码的意图，而且要明了各种测试条件，输入和输出，这样就可以测试出在其他测试条件下可能未测出的功能。正是进行了单元测试，我们才会更加关注函数和过程。
迷思4：单元测试使得文档编写更加困难
单元测试不但不会使文档的编写更加困难，而且会让文档的编写更加细致，这不是坏事。没有人真正喜欢编写文档，不过单元测试使得编写文档不再那么费劲。开发人员发现在进行单元测试的时候编写文档会更加容易一些，此时编写文档是对单元测试中各个过程和函数的反思。
事实是：可以把单元测试的结构和划分重复应用到问答给你编写中，这样你将不仅仅可以编写出更高质量的文档，而且编写文档会更加容易，更加舒服了。有一些开发人员把产品的蓝图做为创建单元测试的启发点，同样可以把他们看作编写文档的框架。
迷思5：一旦项目结束，那么投入到单元测试上的工作就废掉了
完全不是这样的。如果你曾经重用过代码，那么你将会意识到你所做的一切都是资产。
事实是：在你在一个项目中采用了以前为另一个项目写的代码，或者对这段代码进行编辑的时候，你可以采用相同的单元测试，也可以对这些单元测试进行编辑。在同一个项目中使用相似的测试代码段也是没有问题的。
迷思6：单元测试就是浪费时间
你要弄明白什么才是浪费时间？
- 一而再再而三地修改同样的漏洞
- 在整个开发过程中编写或者重写验证代码
- 修补了一个漏洞，不料在其他地方莫名其妙地出现另一个漏洞
- 在编写代码期间被意外打断，完全不知道该怎么办
拒绝进行单元测试是可以理解的，不过许多开发人员只有在使用单元测试完成一个项目以后，他们才会称赞单元测试多么的好。
事实是：你只需编写单元测试一次，但可多次运行。这与你对其他代码的修改没有任何关系。一开始进行的投入会得到长期的回报。
迷思7：这段代码已经非常简单了，为什么还要编写测试代码呢？
代码似乎很简单，然而直到出现问题的时候，此时事情就不再那么简单了。编写单元测试，甚至为简单代码编写单元测试，毫无疑问可以增加项目的稳定性和安全性。
事实是：简单的代码需要简单地测试，不要找什么借口。
迷思8：只有在许多人进行开发的时候才需要进行单元测试
在有许多开发人员进行开发的时候进行单元测试是一个很好的策略。然而由于只有一个开发人员而不进行单元测试则显然是个错误。在许多开发人员开发时进行单元测试所能带来的要好处也适宜于单个开发人员。
事实是：单元测试对一个人组成的团队的帮助同队50个人组成的团队一样多。而且从资产保护的角度看，让单个人掌握所有的东西甚至会冒更大的风险。
迷思9：单元测试对程序调试没有任何帮助，或者说不能防止漏洞的出现
绝对不是这样的。单元测试可以让程序调试更加简单，因为这样你就可以把精力集中在有问题的代码上，修补问题，接着再重新合并修改后代码。在增加 功 能的时候，它还可以防止引入漏洞，尤其在使用面向对象方法编程的时候，它还可以阻止问题令人非常沮丧地反复出现。单元测试不能确保100%的排除漏 洞，不 过它却是减少漏洞的好方法。
事实是：单元测试虽然不能解决你调试过程中遇到的所有问题，但是在你发现漏洞的时候，单元测试中相互隔离的代码可以让漏洞的修补更加容易。根据开发人员中单元测试的铁杆粉丝所说，进行单元测试的最大好处就是让程序的调试非常容易了，简单了。
迷思10：单元测试让你采用的编码方式有重大改变
编码方式有重大改变？是的。编码方式更好了？是的。哪些非常依赖全局变量和单例模式进行编程的开发人员发现他们编写的代码是紧耦合的。如果要对 代 码进行测试，那么代码必须与数据是松耦合的，单例模式不适合这种场合。大多数情况下，使用全局变量和单例模式的编码不是最好的。如果测试是开发人员为 了追 求更好的编码方式而作更改的原因，那么为什么不这么做呢。
事实是：使用单例模式最大的好处就是它解决了资源竞争问题，这种情况可能你极少遇到，比如进行日志处理的时候。在其他情况下，单例模式编程只是一种老的编程习惯，益处非常少，而且会让代码的测试极度困难。
迷思11：使用单元测试进行程序调试覆盖不全面
这仅仅是因为你不能对整个代码进行调试，但这并不意味着调试覆盖不全面。使用单元测试进行程序调试至少比其他类型的调试效果好。事实上，单元测 试 有一个非常突出的优点是：（如果不是大大地删除，那么就是）大大地减少汇报上面我所提到的漏洞的数量。在开发和调试程序的时候，重现漏洞是一个令人非 常沮 丧的事情。通过单元测试，你可以在增加、修改和删除功能的时候减少引入新漏洞的频率。调试从来都是“全覆盖的”，尤其是在程序运行的设备或者系统差 异非常 大的时候。
事实是：特别是在处理漏洞的时候，单元测试可以确保能找到从来都没有汇报过的漏洞。而且在你进行程序调试的时候，你不需要查看全部代码，只需要修改出现漏洞的地方。
迷思12：单元测试增加了开发费用
能让最优秀的开发人员落泪的事情是进行代码更改。项目经理，总经理（CEO），财务总监(CFO)和其他高级管理人员为了让项目盈利，他们说出 自 己的想法，然后算出后期的开发费用。在你为了盈利而付出实实在在的努力的情况下，管理人员却要求立即进行大的修改或者决定抛弃这几个月的工作，因为他 们发 现这个功能没有什么市场。管理人员想让一个产品真正的赚钱，那么有时候这就意味着要进行大型修改或者要快速地进行大量的工作重心的转移。
事实是：通过降低进行大型修改的难度，开发人员可以更灵活地满足产品需求，这也会增加产品经济上成功的机会。编写可无缺陷运行且优美的代码是令人钦佩的，更好的情况是它能获得经济上的回报。
虽然对单元测试有许多误解，但是对软件的测试依然受到高度关注。这里罗列了单元测试的12个迷思和对应的事实；希望你能以这些事实为鉴，以便以后能够更有效地进行单元测试。
更多新体验，欢迎试用Parasoft与PRQA旗下的各种测试工具。另外还有5折限时抢购和免费领iPhone?6、iPad?air等好礼!