Martin Fowler在《企业应用架构模式》一书中说，用领域模型来组织业务逻辑是一个开始使用比较困难，但一旦掌握之后，并体会到他带来的好处之后，你就会对他爱不释手，甚至做很小的应用程序也想使用他。（不是原话，但是这个意思）
我觉得TDD也是，让一个从没写过单元测试的人去写单元测试？太困难了。这个比推广敏捷设计，svn，重构以及领域驱动设计等都困难的多。因为很多人已经习惯在测试某个功能的时候，运行系统，然后点击UI，看看有没有报错或是结果是否正确。
大家肯定也能找出一大堆的理由来反对TDD。例如，我不清楚单元测试到底是什么，我不是测试人员，我怎么会去干测试的活？写单元测试花费太多时间了，会影响项目的进度等等。。。
当我还没有体会到单元测试的好处时（是因为我还没有真正的使用），在一次会议上我就给我们同事说：我们与其让我们测试人员进行白盒测试，不如加强我们开发人员的单元测试。虽然我现在还没有认识到单元测试的好处，但单元测试肯定是对开发和系统的质量是有很大帮助的，以后我们要像习惯使用重构一样使用TDD。
但事实证明，单元测试驱动开发带来的好处可能比我们想到的还多。
单元测试要从考虑怎么使用将要开发的这段代码开始，写单元测试，然后再写这段代码，这样就明确了这段代码的使用方式，使代码更加简洁，易用，并且明确了设计思路。你不可能让你的同事去用你写的自己都认为使用都很麻烦的代码。
单元测试可以最大范围的测试边界条件，特殊条件等，保证了系统的质量。
单元测试为重构后的代码提供了检测保证。
单元测试被保留下来，可以反复的批量测试。
单元测试代码也明确告诉你的同事，你写的这段代码怎么使用。
。。。。。。
怎样才能说服你的同事使用TDD呢？
首先你的同事技术水平应该差不多，而且具有上进心。如果他连写代码都写不好，整天浑浑噩噩的过日子。即使再好的技术，再好的开发体验他也不会有什么感觉的。
再者就是以一个实际中的编程实例给大家讲解TDD怎么帮你完成高质量代码的。从起初设计，到编写测试代码，到明确代码块要提供的功能，到编写代码，到单元测试，再到重构，再到单元测试为重构的质量把关等等。
还有最重要的一点，就是一定要让他们亲自去尝试，尝试过后能体会到其中的价值和好处，他们自然而然的就喜欢上了单元测试。
其实我也是刚开始实施TDD。只是我是自己给我自己推广，在我不知道TDD会给我带来多少好处的时候，我就确信他会给我带来美妙的编程体验。所以整个过程我都是在自己说服自己，自己强迫自己来做。不过没有多长时间，能体会到其中的美妙之处，就会喜欢上TDD。
现在我还是一个TDD初学者，在慢慢的体会TDD带来的好处。。。