TDD之所以让你安心，主要是每次编写代码之后，运行测试会出现一个绿条，告诉你测试通过。这样，你可以放心大胆的向前继续，因为你的代码并没有破坏任何东西。究竟是什么让你感到不安，显然是那些测试没有覆盖到的代码。你又仔细翻看了一下那些没有测试覆盖的代码，你的思路一下子清晰起来。之所以这部分让你不安，因为里面除了那些确实不好测试的部分之外，里面还有一些逻辑。如果只是那些真正不好测试的部分没有被测试覆盖到，你会觉得心里还有一些安慰。你确定了，真正使你不安的就是与不好测试的代码共存亡的这些逻辑部分。
如果测试可以覆盖到这些逻辑的部分，至少从感情上来说，就可以接受了。那怎么才能让这些部分被测试覆盖到呢？你仔细观察着那些没有测试的代码，如果这样做，这个部分就可以测试了，如果那样做，那个部分也可以测试了，一来二去，这些貌似不可测试的代码可以分解出许多可以测试的部分。
你的心情一下子好了许多，因为这么做终于可以让测试的覆盖度达到让你心理上可以接受的范围。不过，新的问题也随之而来。我在做什么？拆来分去，这不就是设计吗？怎么走到这里来了。我不是在分析单元测试的问题吗？对了，我最初的问题是TDD，怎么一路跑到设计上来了？
TDD？设计？
你突然发觉自己对TDD的理解有一些偏差。TDD，并不代表不需要设计。读过很多书的你突然想起了Robert Martin那本著名的《敏捷软件开发》，上面有一个关于数据库访问的例子。那个例子里面，前后两个版本的差异正好就是考虑设计的结果。通常，在设计中考虑测试，会很容易找到设计中僵硬的部分，让程序更加灵活。再进一步，如果在开始动手之前，稍微进行一些设计，这些问题还是可能注意得到的。你突然觉得，正是因为TDD本身过于强调测试的价值所在，让你忽略软件开发中很重要的部分：设计。
思路一下子清楚起来，TDD其实不只是“红——绿——重构”，它还是与设计相关的：在动手之前，还是要有一定的设计，而且，在设计中要考虑测试的问题。终于解开了心中的困惑，现在的你，对于TDD有了一个新的认识，虽然这个认识不见得是什么终极真理，但至少是通过自己的思考得来的，这让你更加相信实践出真知的道理。
理清思路后，你更加坚信TDD本身的价值所在，也坚定了在日后开发中继续使用TDD的念头，当然，目光远大的你已经盯上了其它的敏捷实践。
文章来源于领测软件测试网 https://www.ltesting.net/
