<h1>firebody</h1>

版权声明：转载时请以超链接形式标明文章原始出处和作者信息及本声明
http://firebody.blogbus.com/logs/289807.html

帖子地址：http://forum.javaeye.com/viewtopic.php?t=6379

看了这个帖子，我心情久久不能平静！
很多话我说不出口，只是想干嚎几声！
你们每一个人的观点都是很有意义的，也是富于经验的，特别是chron，dlee,O6Z的帖子，简直是一语中的，感谢所有参与这个篇帖子讨论的人，感谢他们为我们奉上了关于TDD开发的见解！一鞠躬，二鞠躬！
特别是O6Z其中一句话：
[quote]
实际上使用TDD的过程是这样的，先对程序要完成的任务制定一个类表；然后选择某种策略确定这个类表中功能的优先级别；对最优先的功能进行分析，转化为一个具体的测试程序；运行这个程序，应该会得到一个错误（但是确实存在某种可能你得到的是一个pass）；直接性的去使这个测试程序运行起来；重构使代码达到清晰而可工作。
[/quote]
其实它已经大概而且简明的道出了TDD的过程。但是太简明了可能很多人还是不清楚TDD在实际应用中的实施过程。我要从O6Z的这个概括抽丝剥卷般细细说开来！
”先对程序要完成的任务制定一个类表“：TDD与OOD一样同样是建立在对业务用例的详细分析基础上，针对每一个核心用例，我们一一分析，分析过程中我们会得出一些类表，这些类表一般是核心领域模型，随着用例分析的深入，这个核心领域模型的架构会逐渐完整，层次逐渐形成，但在分析用例的过程中，这是复杂而且关键的过程，我们往往会在分析到后面的用例时推翻前面所建立的核心领域模型（这也可以叫做分析重构吧），直到分析完最后一个核心用例，整个领域模型已经初步完善。
“对最优先的功能进行分析，转化为一个具体的测试程序” ：上一步完成之后，我们的领域架构已经形成，接下来，我就要以用例实现为原则 以领域模型为中心进行正式的TDD开发。针对每一个核心用例，我们都可以用一个TDD来完整定义它，注意这个“定义”，我们在TDD中的所有asert必须完整而明确的定义用例完成的状态，而不仅仅是一部分状态。
“直接性的去使这个测试程序运行起来”：接着就是针对测试以及遵循我们已经确立的核心领域架构原则，直接实现测试。说白了就是编写实现代码。为了能够准确的编写，一般我们需要一个静态模型和动态模型加以指导我们的代码编写。这也是OOD的概念吧！
“重构使代码达到清晰而可工作”：这个就不用说了，但是我想还需要补充一点，在编码时，可能我们针对测试的失败，还要重构我们的UML模型，因为直到测试失败，我们才可能发现一些不易被发现的设计失误，从这点上来说，TDD确实是在尽力使得OO模型实现功能需求。