TDD + 重构的开发方式下代码可读性的看法：没有最好，只有更好

o6z兄弟，我也相信TDD的测试不是unit test，如果我做TDD，肯定不会仅仅靠unit test来驱动。
但是，TDD相关的书里面举的绝大部分都是unit test的例子。问题就在这里。
每一本关于测试的书里面，有很多种类测试的。但是除了unit test以外，很多别的测试和设计之间是存在着一定的代沟的，毕竟，除了那些比单元测试更加细粒度的测试以外，只有单元测试才能够在编码之前写，也才能够称之为驱动。我也在找一种从非单元测试到编码的一个过度方法。那样的话，就很完美了。

上次质疑 JUnit 那篇文章我后来仔细看过了。作者除了质疑 TDD，没有提出什么可行性更好的替代方法，所以全部是破坏而没有任何建设。在后面很长一段质疑 Martin Fowler 宣传这些东西出于牟利目的，就有些以小人之心度君子之腹的味道了。摆事实讲道理可以，人身攻击就算了，这是我所不齿的行为，作者确实有非常重的酸葡萄心理。其实 Martin Fowler 的书籍文章可信度还是很高的。如果 Martin 说话一向是出于牟利的目的早就被人揭穿了，怎么可能混到今天呢？

TDD中的测试是基于功能的而不是基于结构的。你写这个测试的时候你面对的结构根本就不存在，谈什么unit test。
是不是用JUNIT就是单元测试？答案那么简单的摆在你的面前。
TDD过程的第一步是写一个测试程序，这个测试显然是不针对具体的结构的，而是针对需求的。TDD本质上说就是一种需求驱动的开发，并且由于其存在一个确实的标准——测试程序，从而带来了设计的前瞻性和强预测性。
而实际上TDD开发过程往往被很多人误解，而当你仔细看看某人推荐的TDD第二部分的时候就会真像大白。
实际上使用TDD的过程是这样的，先对程序要完成的任务制定一个类表；然后选择某种策略确定这个类表中功能的优先级别；对最优先的功能进行分析，转化为一个具体的测试程序；运行这个程序，应该会得到一个错误（但是确实存在某种可能你得到的是一个pass）；直接性的去使这个测试程序运行起来；重构使代码达到清晰而可工作。
我不知道什么地方让你会觉得这样的一个测试程序是一个基于结构的单元测试？你为什么会有这样看法，我实在不能理解。

TDD这一类实践性很强的开发方法，应该是在实践中慢慢摸索、权衡和体会的，它不是“必须如何”、“只有这样”的有非常严格定义的理论论证过程，因此，用TDD来开发，只能依照个人经验来把握好一个“度”。

下面这段话，是从网上找到的，我觉得对经验比较少的人有很好的启发。

这里看来有必要澄清一下单元测试unit test的概念。unit test可以分为黑盒和白盒两类，前者又可归为功能性测试，包括边界值测试、等价类测试、基于决策表的测试等等不需要了解单元内部结构的测试；后者称为结构性测试，包括路径测试、数据流测试等。所以说，unit test并不仅仅等同于基于结构的测试，是不是单元测试关键看你定义的单元的粒度和测试的对象，而不是根据功能性或者结构性来分的。
TDD中所谓的单元测试，实际上指的是黑盒的功能性测试。在面对对象领域中，单元的粒度可以分为类和方法两种，一般都指类测试。同时，因为一个类中通常有多个public方法，类单元测试中也包括这些方法的调用序列的测试，也起到了类内方法的集成测试的作用。正经的类中，公共方法除了创建方法外都应当来源于某个接口，因此我将此时的单元测试称为基于接口的测试。
一个OO系统中起到关键作用的测试是类集成测试，或者说构件集成测试。关键在于构件的交互问题。而这样一个测试，不能够先于代码编写(在集成测试中对于所测试的那些类使用Mock是没有意义的，只有那些非测试对象才可以Mock。此时，如果先编写类集成测试，是不符合XP的步进精神的)。所以所谓的测试驱动，并不是以集成测试来驱动的。
那么，剩下的是什么，我想大家都应该想得明白。

以上关于单元测试的解释，如果还有疑问的，建议找一本正经的现代软件测试或者软件工程的书(现代的原因是老书可能不涉及到面对对象测试)读一读。

我觉得很奇怪：出于牟利的目的有什么不好？只有当一件事关系到这个人的切身利益时，他才会真正地想把这事做好。就拿Martin Fowler来说，他是一个顾问，一个技术传教士，如果他做这些事不是为了牟利，我凭什么相信他宣传的是好的东西？恰恰因为他做的每件事都是为了牟利，我才真正相信他宣传的技术是有利于他的客户，从而有可能有利于我。

我一直想不通某些人的逻辑：牟利就不好？慈善行为才好？如果我做软件不是为了牟利，客户怎么可能得到好的软件？我们公司从来不要实习生，恰好就是因为他们是为了学习而不是为了牟利，所以他们做的东西根本无法保证质量。

hehe,这是一个短视与放眼长远的问题。如果认为Martin是短视的，则有可能有不择手段牟利的几率，但如果是目光长远的，要在这个道上混下去的，那肯定不会为了牟一时之利把自己的名声给砸了，从而牟不了长远之利。
我觉得必须相信Martin不是短视的人，也相信他的客户不是笨蛋。
不过不谋利的人里面也有值得相信的，比如GNU的那几位。但那是异端。开源对于大多数参与者而言，都应该是个双赢的格局。不少人就因为开源而名声远播，最后被一些公司高价招揽。

兄弟，我不想和你争论这个问题。你可以继续奇怪上十年八年，这是与我毫不相关的事情。我还有比争论这个问题重要的多和有趣的多的事情要去做。
还是不要把话题扯开吧。如果不满我的答复请发站内私信给我，可以吗？

    首先，庄兄，我非常赞成通过变量和方法的重命名可以删除掉大量的多余注释，我也赞成尽量简洁的程序可以代替许多注释。我没有说，也从来不会说一个程序要堆砌大量的注释，我想楼上的几位朋友都是误解我了。我的意思是，注释是不能完全代替的，简单地讲，不可能什么程序都可以简洁到一看就明了的。注释有它存在的必要性，只是在使用它上面可以灵活。我很反对一些人，就自以为是的认为注释完全可以不要了，这纯粹是宣扬个人的一种情绪。
    potain说，比如有些程序，我们可以指出书上说明的算法，没错，但是我想说，还有许多的程序根本就沒得算法给你提供，或者没有书籍给你提供，只有一种思路。这是你怎么引用？简单地讲，在许多最优算法中必须用到goto，只是多少的问题（我记得有一种，我说不出名字了，最少用到了9个goto），如果是你自己实现，也许存在更多。如果没有注释，单凭一个思路就能看懂程序？就能知道实现与思路是否真的符合？不至于吧。
    我重视重构，我相信简洁明了的程序远胜于繁杂罗嗦的注释，但是，这并不意味着注释就可以完全被代替

楼上的其他朋友不好意思，我只看来庄和potain的帖子，也就立即回帖了，没有看到大家讨论和我说的完全不是一个问题。
   算是一个滥贴干扰大家视线了，呵呵。各位，不要介意。