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

别人否定了有什么关系吗

那是别人的事情，如果你有切身的体会认为是有用的，何苦去关心一个JUnit才用了几个礼拜的人（或者根本就没用过）的观点呢

怪怪的，如果觉得JUNIT有问题，干吗还要用很长时间，可不是长时间用，又似乎很难发现JUNIT的问题。

我的问题是：在很多环境下，实现不了或者很难实现自动测试，那么对于这种情况，还能否使用TDD。

youcai
看看dlee推荐的《测试驱动开发》的第二部分，看看kent是如何用TDD的方法开发TDD所需要的测试工具的。

这话说得就没意思。我们——我是指，JavaEye论坛上的所有人——讨论任何问题、说任何一句话、评价任何一个产品的大前提就是“没有银弹”。我们是在承认没有银弹的基础上讨论一个东西好或者不好、有用或者没用。如果连这个大前提都忘记，确实没有继续讨论的必要了。

我不知道前面诸位是不是和我持有同一观点，就是说任何东西都有一个适用范围，都需要因地制宜，具体情况具体对待

意思就是说，我从来不会去认为一样东西是放之四海皆准，对于TDD来说，我认为是非常高效、非常实用的一种开发方法，但并不是说我们在任何项目、项目的任何阶段都要采用TDD来开发，也不是说我们用了TDD就其他什么事情都不做了，任何东西都需要权衡。所谓经验，就是你无数次权衡的成功和失败的经历。所谓水平，就是你是不是在权衡中把握好这个度。

这些自然是废话，不过我不知道别人是不是和我一样看待开发问题。

很多问题不能全部TDD，但是通过努力实现可测性，或者努力让一个问题的大部分可测，能够把一个复杂的问题分解为几个不同的部分，其中某些可测、某些不可测

也就是，我们应该尽量把一个看起来完全不可测的相对较大问题进行分解，让不可测的部分尽量变少，这本身就是一种分析技术。

TEST DRIVEN DEVELOPMENT是让你以TEST为导引为线索进行开发，这就和USE CASE DRIVEN DEVELOPMENT一样。USE CASE一样是不可能包含所有的需求的，我们是不是也要对此进行一下讨论？
说TDD并不是说TEST就成为了我们唯一关注的，并且也不是说TEST是开发过程中最重要的。它只是告诉你应该首先明确你要完成什么事情，并把这个事情用测试的方法固定下来。TDD不能代替GOF，也不能代替需求分析，更不能代替清楚的头脑。它只是提供了一个新的解决问题的方式，仅此而已。

我同意 potian 说的这段话。在没有 TDD 替代方案的时候我还是愿意实践 TDD 的。不多说了。

兄弟，具体说说你的一些 TDD 实践经验好吗？这段话对大多数人有帮助吗？这方面的东西你写的很少啊。

左看右看我还是觉得你所说的TDD和我看到的TDD不是一回事情。你说的那个更像是Test First的做法。TDD中设计是浮现的，或者是测试驱动的设计, test(而且主要是unit tests)是整个开发的中心纽带，否则字面上就匹配不了"驱动"两字。
不过这也没关系，只要觉得自己的那种TDD方式挺好就可以了，未必一定要按照TDD的原意来办。如果你认为在总体设计基础上进行有限度的test first开发，那么就和我的观点没区别。如果不是，你就回避不了这个设计问题。用测试把要做的事情固定下来是一回事情，根据测试搞定设计是另外一回事情。前者最多也只是test first而已。
不过，没人说过要由TDD来搞定业务分析，至于use case是不是包含全部需求，我觉得这里有一个概念上的问题。use case驱动的开发中，use case是业务需求的唯一入口点。至于其他的非业务需求，本身就不是通过use case表现的。

我是本着懒得想两遍testcase而开始应用TDD来编程的，我想我应该继续下去。