是谁又揭开了皇帝的新衣？Mile Spille，我的偶像

终于，Mike Spille说出了我一直在心里困惑的话。或者说，揭开了皇帝的新衣。我越来越喜欢Mike Spille的文章了，从两阶段事务、Groovy、与Jboss家族的战斗，直到这次的观点，每次我都感到这个哥们是一个干实事而又敢鸣敢放的人。就好像一个股评家和真正的操盘手，给人的感觉是完全不一样的。
  全文请见
http://www.theserverside.com/blogs/showblog.tss?id=Unitized

不说了

为什么不说了？

很好的质疑啊，多听听反方的意见也没什么不好。现在质疑 XP 的声音越来越多了。
我最大的疑问就是很多场合下单元测试是很难写的，如果还强迫我一定要做 TDD 那我还活不活了？我总要写些至少表面上还能工作的代码骗那个大头给我点 money 吧？
如果这个疑问最终解决了，那么我肯定无条件接受 TDD 和 XP。一个真正的银弹诞生了，不是吗？

从我的角度来看，MS的这篇文章的矛头对的是TDD，或者说是过分以unit test为中心的开发方式。
我的感觉越是难写的test越可能不是unit test，而且决定应用成败的往往是这些难以穿进unit test衣裳的测试。或者换一个角度来说，保障系统中个组件的交互的正确性（包括接口的设计、动态依赖的设计、交互序列的设计等等）要比保障每个组件的正确性难得多也重要的多。而unit test习惯于把组件孤立出来测试，最多只是保障了一个次要方面。
即便要测试驱动，以交互测试为核心也要比以单元测试为核心要好。现在所谓的TDD，给人更多的感觉是unit test driven development.

charon，看看我去年说的一段话：
http://forum.iteye.com/viewtopic.php?t=1407
事实上这些疑问我至今仍然未能打消。我看了 Kent 的《测试驱动开发》，但是感觉可行性仍然不是很大，因为很多在 Kent 看来如此明显的事情对于我仍然是晦涩难懂的。为了更加深入地了解 TDD，我订购了另外一本书：
《测试驱动软件开发——实用指南》

主要是为了学习更多的测试技巧，到不是为了在我的团队中 100% 实行 TDD。

在我看来 XP 实际上仍然不够极限，仍然无法很好地解决我们的问题。所以我觉得把目光投向其它敏捷方法（FDD、ASD、Crystal）似乎更好一些，其它这些方法从各方面看来似乎都比 XP 要成熟。
其实 Cockburn 在《编写有效用例》中就已经对 XP 提出了质疑，看书比我仔细的人似乎不是很多。

TDD==UNIT TEST DRIVEN DEVELPOMENT
还说什么好？索性不说。
但是你不管如何置疑也不能否认
USE CASE==TEST CASE
一个architecture如果不能提供与之相关的保证其实现是合乎其最初构想的TEST CASE，你认为这个architecture是一个完整的结构吗？
可“孤立出来测试”的组件才是一个architecture需要的作的最基础的工作，或者说一个组件不能被“孤立出来测试”，这个组件你还能叫它为组件吗？
其实这个争论真的没有什么太大意思，就如同争论XP没有很好的风险控制一样，是一种典型的基本的概念不清楚的逻辑混乱。

o6z 兄，学术上的是非似乎不能完全作为我们判断对错的标准吧？就象以前 AST 与 Linus 争论微内核和单一内核到底哪个好一样。以前的大部分人都认为 RISC 好于 CISC，Intel 动摇了吗？没有。
谈点具体的好吗？如何真正做好 TDD、做单元测试的一些切身经验，很少有人说这些话题。是不是大家都在观望？摆个擂台，把那些难以测试的情况发布出来，大家讨论一下。要是大家都很忙，不妨到周末来谈一谈。据我所知，实际上现在除了 potian 外，大多数同志感到最难的就是如何真正写好单元测试（真正写好，起到作用，而不是走走形式敷衍了事），为什么要捂着不让大家说呢？如果这个问题解决好了，推广 TDD & XP 的障碍就完全不存在了。

论坛上严格按照 TDD 方式来做开发的同志请举一下手吧。

dlee
你说你逻辑胡乱你就自己出来给我提供证据，inter现在的搞的安腾是什么框架？inter现在搞的所有芯片其实内核已经是使用了大量的RISC，而不是CISC。
做好TDD的第一步就是要搞清楚概念上的TEST究竟是什么，是不是仅仅是UNIT DRIVEN CODING，还是TEST CASE DRIVER 分析、设计、实现。这些基础性的概念不统一，我们就不能建立一个基础性的讨论语言环境。
实际上TDD的流程是这样的（当然TDD不是XP的独有，也不应该被认为不能和别的方法相结合）：
USE CASE（或者类似的需求工具）——TEST CASE——TEST CASE的一个部分（优先完成的一个部分）——UNIT TEST或者其他的测试方法以保证其设计动机的显示表达——对这个细化的TEST进行分析——对这个细化分析进行设计构想——对这些构想进行实现——对这些实现用对应的TEST CASE进行验证——反复实施并在适当的时候重构。
有些时候对于某些细节的代码是很难进行UNIT TEST，但是如果就此就认为对于其最初的需求动机也不能进行TEST，是不是就太不合适了。

hehe,从我现在接触的TDD的东西来看，即便是by example那本书，最大的感觉就是用单元测试驱动。我不否认o6z你可能还有其它的方式，但是XP的那些只能称作是单元测试。
而且，请你注意一点，没有谁去否定孤立的单元测试，但是我认为更加重要的是交互测试。你要是以为用几个针对architecture的junit的test case就能保证实现的architecture是按照构想的，那也太天真了。
交互测试因为其复杂性只能是脚本驱动的，否则只能针对toy级的应用。一般的复杂系统本身就像一个由n多组件装配起来的巨型状态机。用针对unit test的工具是很难做这个东西的测试的。