3. 聆听和讨论（业界怎么说）

　　带着这些问题和困惑，我在网上查询了大量相关资料，牛人的文章和业界的讨论。很容易看出，业界对于单元测试的目标，作用，方法和手段都有很多争议。

　　3.1 什么是（不是）单元测试？

　　3.1.1 单元测试和发现缺陷无关(http://blog.stevensanderson.com/2009/08/24/writing-great-unit-tests-best-and-worst-practises/)

　　【摘要】单元测试不是一个发现缺陷或者检测regression defect的有效方法。其一，单元测试，根据定义，是用来测试特定代码单元。然而，一个系统往往是一个大量单元的复杂集成，单元测试很难发现集成的缺陷。其二，相比单元测试，手工测试或者自动化集成测试更容易用于检测缺陷。

　　3.1.2 一个测试不是单元测试 如果 -

　　和数据库交互

　　需要跨越网络

　　需要访问文件系统

　　不能和其他的单元测试同时运行

　　需要配置文件才能运行

　　3.1.3 测试驱动开发和验证（verification）无关，和规范（specification）相关

　　测试驱动开发并不意味着单元测试驱动的开发。实际上，测试驱动开发这个词非常容易引起误解。在TDD的大佬们眼中，单元测试只是测试驱动开发的工具，而不是目的。测试驱动开发更关注这个代码单元应该如何运行（behave）而不是这个代码单元实现是否正确（verification）。之所以叫测试驱动开发，意义及在于此。最近你可以看到一个新名字的兴起-行为驱动开发（Behaviour Driven Developemnt）。BDD更强调一个组件应该如何工作，以及寻找一个简易的方法来规范行为。

　　3.1.4 为什么需要单元测试？

　　可以单独地测试每个单元

　　可以用于验证重构后的代码

　　可以用来确保不会破坏其他人的代码

　　可以用来提高系统设计，比如说，不能单元测试的代码将不会出现

　　3.2 对怎么样的代码做（不做）单元测试？

　　参考http://blog.stevensanderson.com/2009/11/04/selective-unit-testing-costs-and-benefits/

　　【摘要】 该文作者在总结3年的TDD实践经验的时候，反复认识一个情况：对于某些类型的代码，单元测试工作得很好，也极大的提高了待测代码的质量；但对另外一些类型的代码，单元测试耗费了大量的时间，并没有起到辅助设计和减少缺陷的作用，同时还导致代码更加难以维护。

　　基于这个想法，作者画了一张图来表示：

　　作者认为：

　　（1）代码本身很复杂但是对外部的依赖很少（左上），最适合单元测试，因为耗费较少和收益较多。一般来说，某种算法（排序），核心业务规则，数据解析类似的模块属于这样的代码

　　（2）带有很多依赖的琐碎代码（Trivial Code with many dependencies，右下）：称为协调者（Coordinators），因为这些代码主要用于集成多个代码单元和安排代码单元之间的交互。这些代码不适用于单元测试，因为耗费很高，收益却不大。

　　（3）代码很复杂而且外部依赖很多（右上）：过于复杂的代码，需要重构。

　　（4）外部依赖较少的琐碎代码（左下）：这些代码可测可不测，因为重要性不高，复杂度也不高，加单元测试的意义不是很大。