TDD到底是什么，它是怎么做到演进出一个优良的设计的？这些疑问驱使着自己不断地思考，并看了很多讨论，下面是自己的一点心得。
testCase反映的应该只是需求，不能把设计掺杂进来，设计不是它考虑的问题，它只提出你要做什么，至于怎么做，它不管。TDD是需求驱动，在读kent的《tdd》时这样的想法若隐若现，没想到还真有人也这么说，与偶暗合。
设计，由重构来负责。每次让testCase测试通过后，就应该试图进行重构，恰当的重构能够带来恰当的设计。
另外，参考如下帖子： http://www.iteye.com/topic/6551。我的理解是，如果需要算法优化，则需要进一步进行tdd，增加需求即算法优化，编写testCase、编码、测试通过。得出来的结果甚至完全推翻了之前的算法，这点光靠重构是无论如何也做不到的。这篇帖子的主要议题是，tdd需不需要先验的宏观构思，在它的指引下进行tdd。我的观点是，不需要，但必须把它的 目的转化为testCase，或是需求。为什么要这个宏观构思？比如这篇帖子，它就是要解决效率问题，那就编写一个测试效率的testCase，然后由它驱动着自己寻找最优算法；而不是一开始就按该算法的套路编码，这就不是测试驱动了。所谓宏观构思其实也是一种需求迫使它出现在你的脑海里，既然如此，就把这需求也暴露出来。 现在仍有一个问题没有解决，kent说过，编写独立的测试能够实现“高内聚、低耦合”，这一点我还没有领悟。假如做到了这点，而重构又及时而恰当，那测试驱动的功力应该就到位了吧。