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

to o6z：
我觉得我们讨论问题又有发散的趋势，我还是喜欢曹晓钢的那种讨论方式。其实 Mike Spille 这篇文章讨论范围限定的是比较窄的，就是质疑仅仅依赖 JUnit 的自动测试来保证软件质量是否足够完备。
我说的话当然有很多问题，但是这只是细节。我没有完全否定 Test 啊，否则读这些书干什么呢？
你说的“或者其他的测试方法”，我们正是采用这些测试方法来做测试的。自动测试我们也会做一些的，不过不是完全采用 TDD 的方式。当然我们做的不够好，但是我们目前还能为客户提供他们真正需要的产品，我觉得这对我们才是最重要的事情。我们逐步对各方面进行优化，主要是为了提高我们上述的能力，而不是完全与某种开发方法银弹靠拢。

还有一个非常重要的问题，除了单元测试，其他的测试是没有办法驱动设计的。从测试到代码之间有一个很大的沟在那儿摆着，如果硬要驱动，就只能是upfront方式。

dlee
我并不是要和你们讨论这篇文章，我只是和你们讨论最基本的TDD的概念，这概念我们都不能达成统一，还能讨论什么有关TDD的事情呢？我觉得最迫切要解决的就是认为TDD就是用Juint写几个testclass。TDD绝对不是UNIT TEST DD，更加不是TESTCALSS DD。
对于质量的问题我想还是应用传统行业的解决方式比较好：质量是生产出来的不是检测出来的，但是质量的保证是依靠更加严格的检测作为基础的。
把TEST CASE偷换为UNIT TEST最后偷换为JUNIT这样的方式来置疑TDD，根本就是一种为辩论而辩论的方法，根本就没有什么学术价值。

XP 的核心是 TDD 和重构，TDD 的所有实践都是围绕 JUnit 这个工具来做的。TDD 只做 Unit Test，没有做其它测试（当然基于 JUnit 的框架，例如 HttpUnit 可以用来做功能测试）。我不知道离开了 JUnit 我们还如何来谈论 TDD，实在是太虚幻了。Kent 本人都说他学习某种新语言（例如 Python）时先要为这种语言实现一个 xUnit 框架。《测试驱动开发》第二部分详细描述了他为 Python 开发 xUnit 框架的过程。在没有 xUnit 框架的某种语言上如何做 TDD？谁能告诉我？

charon 的原意就是为了讨论这篇文章。charon 的目的是为了完全否定 TDD，但是这并不是我的目的。

其实在敏捷软件开发(Robert Martin版本)中就有几个TDD的实例。第一个保龄球的例子是结果正确逻辑错误。
在那里面我只看到了unit test。或许大家可以认为这些例子太小儿科，但是，那也只能说写书的人的认识只到这个层面。也许大家对TDD认识的层面都要高一点。

我认同的是test first，而不是test driven

dlee
最后说一遍，我实在觉得这个讨论太无聊。
TDD的那个TEST是说使用某种工具进行自动化的测试，Xuint只是实现这个构想的工具，但是绝对不是唯一的工具。某些test case同时是单元测试也是集成测试，并且基本所有的单元测试都可以被认为是整体的集成测试。
如果你所处的环境根本就没有这样的一个自动化的测试工具，你自然不可能进行需要依靠这个工具进行的工作。这点根本就不需要讨论。当然如果一个环境不能提供其测试的套件，我不知道你会不会认为这个环境值得我们去工作。
TDD的问题其实很简单，建立一个标准，监狱这个标准，为达到这个标准进行努力，实现这个标准。如果你偏要狭隘的去把它解释成为写一个testclass，运行它，使它通过，我是实在没有办法。这个时候的任何讨论都是没有学术意义的，只是单纯的吵架。

o6z，我觉得你还是没有理解讨论的重点所在。
我就想问你一句话，你的集成测试怎么驱动设计来着？面向接口的编程，你怎么测试组件组装的正确性。
而且，"基本所有的单元测试也可以被看作集成测试"，也许你从来不用Mock Object?如果用了，那么和Mock集成了就相当于和真实环境集成了？通过Mock的构建来思考真实对象的接口，最终系统中出现了一定程度的重复，Mock和真实接口的同步还是要维护的。
这里的关键不是测试或者自动化测试，而是你的测试怎么驱动设计。如果不用Mock，就只能从底向上构建系统。那个时候没有upfront设计是很难搞定的。如果非要从顶向下，那就只能搭起花架子然后慢慢充实这个架子的肉质部分，但是关节的两端都会变化，所以平衡能力的要求就很高了。
而且，关键的一点，关于TDD的任何讨论都是没有学术意义的。从学术上来说，从来没有人指望过通过test来验证复杂系统的可靠性，更不要说通过test来设计了。所有缺乏形式化的东西都只有扯淡和讲哲学的价值。

我现在就是在为如何做好 JavaScript 的测试而头疼。不是我认为 JS 不是一个值得的工作环境我就不用写 JS 了。我确实没有那么幸运可以工作在一个 TDD 完全适用的环境中。

确实，用 Mock Object 来模拟数据库的行为是我疑问最大的地方，这样测试的结果有多大的可信性呢？可能在下一本介绍 TDD 的书中我能找到希望的答案。以前 potian 解释过对象建模优于数据建模的原因。我觉得 OR Mapping 最大的意义就是让针对数据库的测试变的容易了。

你看这篇文章是一片正常的技术文章吗，除了争论还能干吗，有任何建设性的东西吗，我想Mike Spille 是在感叹自己时运不济，不然的话，不要说MartinFowler，KentBeck和EricGamma算什么东西，他们的JUnit我两分钟就能搞定，代码烂得一塌糊涂，等等等等之类的

怪不得每次这个Mike Spille 出现，TSS就变成了CSDN

冒昧插几句。我不知道什么是真正的TDD。然而我想，即使做不到TDD，也应该写尽可能多的、有用的单元测试。我切身体会到它的好处，有很好的投入产出比。因此，我担心到时以UT难写为由，否定了TDD后，让人以为把UT也否定了。

对于那些很难做UT的情况，我选择不做UT，但尽量避免它的发生。例如写尽可能小、少的JSP。