在日常开发中，我一直在用JUnit做单元测试，而且推崇这种方法。值得强调的是做单元测试不等价于TDD。很多人对单元测试或者TDD看法褒贬不一，我只说自己的对一些争议问题的看法。怎么实践和工具就没必要说了，因为这方面的书籍和文章在网上到处都是，一搜一大片。
说实话，在实践中我也不是先写test case，周围也很少人这么干。我自己的实践一般是把代码写到基本能工作，然后开始写test case。这是个权衡，因为test case写得很早，不符合一般开发人员的思维方式；而写得太晚就和验收太晚一个道理：修改代码成本会变高。而且太晚写test case会丧失TDD的理念。当然，这样的实践和TDD的初衷有些违背。但是，有一个场景我是坚持先写test case的，就是bug fix：先写个test case暴露这个bug（即fail这个test case），然后改代码使这个test case pass。在这个场景下我把TDD定义为Test Driven Debug:)
为啥会这么说呢？可能是因为单元测试掩盖了糟糕的程序内部的结构和实现。我的回答是，没有'银弹'。得确，有可能你看到90%的test coverage，但是代码写得惨不忍睹。这的确不是TDD能解决的问题。好在至少TDD能迫使你写出相对可测试性高的代码，一般来说高可测试性的代码，会低耦合loose coupling。
当然，写test case需要额外的时间和精力。实际上任何事情都是有成本和投入产出的。在写test case这个事情上，就是通过编写test case这种成本，来提高产品质量和可维护性。顺便说一下为啥test case能提高代码可维护性，代码的可维护性对产品开发是及其重要的（你在改前朝代码的时候有多少次有砍人的冲动）。在有良好test case的情况下，test case会变成一种很好的文档，帮助你来理解现有代码。
我就问一句：代码能看到你print在console里面的字符吗？事实上很多的管理系统都是要求自动化的automation。Maven也是有test这个lifecycle的。把单元测试纳入为build的一个必要阶段已经是共识了。回到print这个手段，我在调试一段小代码的时候也常常会用print，简单嘛。但是我只是用它来做调试，而不是测试。
咱改bug最怕的是啥？不是改不掉bug，而是改掉一个bug之后，引入一个新bug！特别是当改bug的人不是当初写这块代码的人的时候。如果当初test coverage足够高，会大大降低由于代码改动而导致的新bug。我自己深有体会，同事改我代码的时候，常常他们会问我能不能这样改或者那样改。除了回答他们对代码结构的问题，我都会加上一句“把test case都跑一下”。看到绿色的bar，心里就有“把秋裤裤脚塞到袜子里面的扎实感”。
七七八八先写到这里。网上很有很多系统介绍TDD的资料可以去看，以上都是我个人的一些见解，谢谢。