Q: 为什么通过单元测试发现的 Bug 很少 ?

　　A: 单元测试不是用来发现 Bug 的， 而是用来预防 Bug 的. 如果采用 TDD， 测试用例完成之时， 产品代码尚未编写， Bug更无从谈起.

　　Q: 那是否写单元测试能提高代码质量了 ?

　　A: 关于这一点， 似乎有人不这么看， <<TDD Opinion: Quality Is a Function of Thought and Reflection， Not Bug Prevention>>. 不错， 代码质量并不必然关联到单元测试， 诸如净室软件开发之类的方法依然可以在没有单元测试的情况下得到高质量的代码， 但这是另外一个问题. 或许主观上， TDD的本质更接近于促使你把质量内建在思维中， 但客观上， 在其它条件都相同的情况下， 单元测试依然能够起到预防 Bug 的作用.

　　Q: 单元测试怎么能反映/代替需求 ?

　　A: 单元测试未必能直接反映宏观上的需求， 但

    功能测试和集成测试能够反映宏观需求.

    单元测试能够反映系统的其它部分对当前单元的需求.

　　而从文本的角度， 测试用例的名字是需求的描述. 换句话说， 你从传统的需求文档中把描述抠出来， 放到测试代码中作为测试用例的名字， 你便拥有了可执行的需求文档

　　一个 RSpec 写的功能测试用例 (不要怀疑， 它确实是可以运行的):

　　it "should show welcome message after login" do

　　login_as_chelsea

　　get :index

　　response.should have_text(/欢迎 chelsea/)

　　end

　　it "should not show welcome message after logout" do

　　logout

　　get :index

　　response.should_not have_text(/欢迎/)

　　end

　　单元测试的例子:

　　public void testShouldBeFreeFrom2amTo5am() throws Exception { //直接业务需求

        ...

　　}

　　public void testShouldThrowExceptionIfCannotFindConfigFile() throws Exception { //来自系统其它部分的需求

        ...

　　}

　　测试用例并不排斥业务层面的需求文档， 一个高层的， 突出业务价值的需求/愿景描述对于快速理解系统是非常有帮助的， 但/只是测试用例以另一种方式描述了真实的系统， 它具有两个突出的优点:

　　它不会说谎， 即永远与系统真实的行为同步

　　它是可执行的， 它可以不知疲倦的， 成本极低的， 时时刻刻， 反反复复的追问你的系统是否符合需求

　　Q: 需求变了怎么办? 岂不是有大量测试用例需要修改?

　　A: 难道不是应该的吗? 难道以前的需求文档在需求发生变化时不需要修改?  哦， 或许它们不需要， 因为没人会关心， 对代码也没什么影响， 需求文档在度过初的几周后便被扔在配置库里再也没人管它了.

　　Q: 我的单元测试编译链接速度很慢， 而且有些条件很难测， 比如内存不足， 或者环境很难搭建， 比如需要网络或数据库， 怎么解决?

　　A: 这是集成测试， 不是单元测试. 你一定把系统所有的组件都编译链接起来了. 那么如果你的测试失败了， 是哪一部分的问题呢?

　　通常单元测试需要满足一个条件: 不依赖任何其它单元， 即隔离性. 实现手段是在测试环境中能够轻易的假冒依赖， 并设定依赖按照我们的意愿进行工作. 一个例子是你的代码依赖 malloc 获取内存， 而你想测试内存不足的情况. 那么我们应在能够/需要在单元测试中使用使用一个假冒的 malloc 来代替真正的 malloc， 并且我们能控制假冒的 malloc 返回 NULL 以模拟内存不足的情况. 关于如何做到这一点， 可参考一些成熟的"假冒"框架， 如 mockcpp 等.