posts - 56, comments - 77, trackbacks - 0, articles - 1
  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理

敏捷质疑: TDD

Posted on 2008-07-13 21:40 切尔斯基 阅读(4532) 评论(4)  编辑  收藏

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/)

  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 { //来自系统其它部分的需求

        ...

    }

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

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

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

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

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

1073x: "这也是很多程序员不愿意作单元测试,并且抵制TDD的原因(虽然他们两者根本不是一回事)。在开发过程中确定什么应该用测试用例描述,什么可以不用,是很重要的。一段产品代码与之对应的测试代码的粒度,数量,都是需要斟酌的问题。"

是的, 这关系到你的测试策略. 然而通常的测试策略对单元测试的要求都是尽可能周全. 于是这就是一个测试设计的问题. 是的,测试代码也需要设计, 也需要重构, 也需要 Domain Specific.

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