一直以来比较推崇在开发中进行全面的单元测试，我觉得单元测试的好处非常多。但是没有真正的用起TDD，在编写功能实现代码之前先编写测试代码，这样的习惯没有养成，意义也没有觉得非常大。因此TDD其实没有真正用起来。直到最近在实际工作中的一个案例让我更加深刻得领悟出TDD开发的真谛！

案例：最近我们开发一个消息中心的服务，该服务要给数十个项目组提供接口，由于各项目组的进度和步调不一致，消息中心服务的项目先开始工作，定义好了接口之后，将接口公布出去，然后就开始实现接口功能，进行接口的单元测试及模拟集成测试。一段时间后，陆陆续续有些应用项目组开始工作，发现了接口定义的一些问题，这些问题有的是接口无法满足他们的需求；有的是有些字段没有；有的是感觉接口使用不方便；反正最终导致的结果是消息中心服务项目组的代码进行了多次返工和修改，浪费了很多时间，至今还没有彻底满足所有项目组的需求。

后来我接收负责其中一个接口的实现，反思之前出现的问题的原因是什么？有什么办法可以解决或者减轻这种问题呢？我觉得最根本的原因是在设计和实现接口的时候，服务提供项目组没有让服务的用户参与进来一起进行设计，服务接口公布出去之后，由于服务用户没有真正去了解和使用，也无法提出问题，等真正开始使用的时候才发现一大堆问题。因为接口实现项目组由于知识和场景的完全认识，无法清楚所有使用方的使用场景，因此导致实现的东西与接口用户想要的东西存在差异的原因。

最终我的解决办法是也许可以应用TDD的思想。让接口用户参与进来共同设计接口，将开发顺序反过来结果就完全不一样。我这次的开发方法是这样的：首先让接口使用项目组自己设计协议接口，我来看接口是否存在问题，然后我写程序实现思路，画程序的活动图，用这些东西与接口的用户沟通，经过协商没有问题后就这样定下来了。然后，接口使用项目组开始面向接口编程，当他们的代码写完了之后，我再开始写我这边的单元测试，接着写实现代码，最终进行集成测试。最终的结果证明这种开发方式几乎没有返工，开发出来的接口几乎没有任何问题。

从这个案例表面看起来好像是接口实现方和接口使用方之间的关系，但是这个道理同样可以应用到软件开发者和软件用户之间的关系。只有用户最了解自己想要什么，让用户参与进来验证需求，能够最大程度的保障需求的正确性。因此TDD能够将软件开发方和软件用户对需求的理解尽可能保持一致，让用户得到他们想要的软件，他们在自己的使用场景下用起来非常顺手的软件。