酷 壳 – CoolShell

春节前的一篇 那些炒作过度的技术和概念 中对敏捷和中国ThoughtWorks的微辞引发了很多争议，也惊动了中国ThoughtWorks公司给我发来了邮件想来找我当面聊聊。对于Agile的Fans们，意料之中地也对我进行了很多质疑和批评。我也回复了许多评论。不过，我的那些回复都是关于中国ThoughtWorks咨询师以及其咨询的方法的。我对Agile方法论中的具体内容评价的不是很多，所以，我想不妨讨论一下Agile方法论中的具体的实践（以前本站也讨论过 结对编程的利与弊 ）。

那么，这次就说说TDD吧，这是ThoughtWorks中国和Agile的Fans们最喜欢的东西了。我在 原来的那篇文章 中，我把TDD从过度炒作的技术剔除了出去，因为我还是觉得TDD有些道理的，不过，回顾我的经验，我也并不是很喜欢TDD。我这篇文章是想告诉大家， TDD并没有看上去的那么美，而且非常难以掌控，并且，这个方法是有悖论之处的 。

TDD简介

TDD 全称Test Driven Development，是一种软件开发的流程，其由敏捷的“ 极限编程 ”引入。其开发过程是从功能需求的test case开始，先添加一个test case，然后运行所有的test case看看有没有问题，再实现test case所要测试的功能，然后再运行test case，查看是否有case失败，然后重构代码，再重复以上步骤。其理念主要是确保两件事：

• 确保所有的需求都能被照顾到。
• 在代码不断增加和重构的过程中，可以检查所有的功能是否正确。

我不否认TDD的一些有用的地方，如果我们以Test Case 开始，那么，我们就可以立刻知道我们的代码运行的情况是什么样的，这样可以让我们更早地得到我们实现思路的反馈，于是我们更会有信心去重构，去重新设计，从而可以让我们的代码更为正确。

不过，我想提醒的是， TDD和Unit Test是两码子事儿 。有很多人可能混淆了自动化的Unit Test（如：XUnit系例）和TDD的软件开发过程。另外，可能还会有人向鼓吹“ TDD让你进行自顶向下的设计方式 ”，对此，请参阅本站的《 Richard Feynman, 挑战者号, 软件工程 》——NASA的挑战者号告诉你自顶向下设计的危险性。

TDD的困难之处

下面是几个我认为TDD不容易掌控的地方，甚至就有些不可能（如果有某某TDD的Fans或是ThoughtWorks的咨询师和你鼓吹TDD，你可以问问他们下面这些问题）

• 测试范围的确定 。TDD开发流程，一般是先写Test Case。Test Case有很多种，有Functional的，有Unit的，有Integration的……，最难的是Test Case要写成什么样的程度呢。
  …

  阅读全文 Read More

( 34 人打了分，平均分： 4.15 )

Loading...