看完老赵精彩的两篇“可测试性驱动开发（上）”，“可测试性驱动开发（下）”。
写了篇回复
老赵，我觉得你说的“可测试性驱动开发”和“测试驱动开发”的结果是非常接近的，可是实际观察下来我觉得不是一样的。我觉得测试驱动开发的一个好处就是从外界向内部逐渐迫近，逐渐的暴露的你意图。意图其实是更接近你的商业流程和商业价值的。所以更接近与“意图驱动开发”。因为TDD鼓励从系统的外部行为向内部行为逐步细化，逐步测试－通过，循环。这样产生的结果就是方法小，方法名考究，高层的代码非常容易读懂（经常达到看起来就像文档）。
可是在“可测试性驱动开发”中，我觉得随时考虑的还是“可测试性”，但是“可测试性”本身与商业价值无关。所以驱动开发的东西就转变为程序员自己的一些“修养”问题了，你可能会倾向于使用模式来解决一些微观问题，让代码具有“可测试性”。这种做法可以产生组织良好的代码，它对于程序员来说易读（容易理解算法细节），但是这样的代码在被维护更久以后容易产生与商业价值的偏离。还有就是“测试性驱动”的经济问题，如果一个测试是纯技术意图驱动的，那么就是追本逐末了。
测试驱动开发中的ATDD（验收测试驱动开发）鼓励你将系统的流程Spec在实现前写出来作为驱动，而BDD则从微观行为上将你的领域模型的行为Spec写出来驱动，这两种方式我想才是经典TDD的“新外衣”，因为他们都继承了“意图驱动”并进化为“商业意图（价值）驱动”。
此文甚好，只是我觉得上面问题是个关键，”目标“最好还是在产生”策略“之前找到比较好，所以才写这个评论，冒犯了 ^___^