敏捷质疑: TDD

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: 单元测试未必能直接反映宏观上的需求, 但

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

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

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

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

  it "should show welcome message after login" do

    login_as_chelsea

    get :index

    response.should have_text(/欢迎 chelsea/)

  it "should not show welcome message after logout" do

    logout

    get :index

    response.should_not have_text(/欢迎/)

单元测试的例子:

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

        ...

    }

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

        ...

    }

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

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

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

原文转自：http://www.ltesting.net