由于公司要实现TDD形式的开发，所以准备了一下，准备在后续的项目中，投入到TDD的怀抱中。
在找一些参考书目的过程中，偶遇《测试驱动开发的艺术》这本书，书中的编码为JAVA派系，但是书的内容却是通俗易懂，书的作者属于实战派的写手，所以一开始几章就直接上具体的例子，然后通过测试，开发，重构，测试，开发，重构。。。的过程来展示如何实践TDD的。
在看书的过程中，我逐渐对TDD有了新的认识，目前已经看到了第三章，通过之前作者的引导，我所理解的TDD是这样的：
TDD，测试驱动开发，是一种软件开发过程的实践，是一种理念，而非实现的工具。它要求软件开发者在开发软件的过程中，按照 测试，开发，重构，测试，开发，重构。。。。的过程，来一点一滴的构建软件的。
映射到我以前的设计工作中，我确实体会到了TDD所带来的便捷之处：
以前的开发：瀑布式的开发，先写功能代码，遇到编译错误的地方，就直接Debug项目，然后让其编译通过即可，没有真正的去检测功能是否是正常的；即便有时候去写一写测试用例，也只是针对核心的业务逻辑进行一下覆盖，没有涉及到重构，测试的过程，所以有时候在开发完毕，发现问题还是挺多的。
TDD的开发：先写失败的测试，然后修改让其通过测试，然后实现功能代码，然后测试，然后重构，然后再测试，再开发，再重构。。。反正就是保证自己每次写的功能点都是可用的，都是通过测试的。等软件正式交付以后，所有的这些测试就可以当做以后系统出现问题时候的检测依据，可以很方便的定位到出错点。如果项目非常大的时候，能够快速的定位到出错点是非常难能可贵的。（在以前花旗做软件的时候，有一个巨大的项目，核心逻辑用c++写，表现层用C#写，粘合层用的CLR c++写，项目中的线程特别多，有时候当表现层出错的时候，需要定位到出错的地方，需要从C#调试到CLR C++，然后再往Native C++调试，过程苦不堪言，最重要的是，整个项目编译一次，需要四五个小时。。。熬过这段时间，才知道TDD的这种机制的重要性，作者的感受，于我心有戚戚焉。致敬。）
但是TDD也不是万能的，TDD能帮我们写出运行良好的软件，不过我们还是要想办法保证交付的功能正好能满足客户的需求。这里我们涉及到了“验收测试驱动开发”这个词，咱们且看且走。