从09年1月份开始在项目中推行测试驱动开发，在实践中有一些所得：
1. （TDD的基本原则）如果需要对代码的逻辑行为做任何修改，必须思考并先创建单元测试用例。
2. TDD的初衷是可以完全取代 Low Level Design。但是在实践中发现，对于大多数新的TDD程序员，要在完全没有详细设计之前写出有效实用的单元测试用例是非常困难的事情。其实这是个思维习惯问题（我们绝大多数人都习惯了用文字来描述场景和问题，而不习惯用代码来做同样的事情，仿佛代码没有文字直观），经过有意识地训练，我发现用测试代码来描述问题更具体，更节省时间。那么对于经验不足的程序员，一个折中的办法是，可以允许他在写测试代码前有一个简单的详细设计文档。但是注意：这个文档不是一个很正式的可参考的设计文档，不是我们的 work product ，它仅仅用于帮助经验不够的程序员进行思考分析。（在敏捷开发实践中，我们提倡 Simple Design，设计不应该描述太多的代码细节）
3. 在设计文档中（无论是 High Level Design 或 Detail Design），我们需要对预期需要的单元测试用例进行描述，比如罗列出单元测试需要测试哪些场景。这有两个好处：
a. 强制设计人员在写设计时就考试考虑如何进行验证；
b. 确保程序员在 coding 时不会忘记某些必要的测试。
4. 如果有 Code Review 的流程，单元测试用例和运行结果也必须是代码审查活动的一部分。
5. 单元测试用例必须要被频繁的执行或重构，团队需要保证提交到版本控制库里的所有代码的测试用例在任何时候都可以成功通过（建议部署持续集成CI的流程来自动化单元测试执行），不是仅仅在开发的时候写一次就自不维护了。而且一个程序员写的测试用例要能够很容易得被其它程序员执行。
6. 尽可能将测试数据和用到它的测试代码放在同一个类中或同一个目录下，尽可能将不同单元测试用例的测试数据隔离，避免互相影响（除了一些基础数据，业务测试数据可以在每个用例测试前创建，测试后清除）；程序员需要保证，单元测试用例的执行不能过于依赖本地数据和环境的配置。
7. TDD的单元测试用例应该从需求，从业务场景的角度来思考和创建，而不是像传统单元测试那用针对每个类，每个方法来写测试。记住：真正的TDD是一个业务驱动的设计和开发方法！
More to be added...