你不会打无准备之仗，于是，你通读了Kent Beck的那本薄册子。通读之下，你对TDD更是充满了信心。因为“红——绿——重构”的步骤实在是简单得令人发指。好吧！总而言之，你已经信心十足的准备开始TDD，步入敏捷的康庄大道了。
理想很美好，现实很残酷。
当你着手在实际项目中体验TDD的时候，一切变得并不像最初看起来的那样美好。虽然你努力的坚持着TDD的原则，但你经常就会发现某些东西不好测，比如你遇到了数据库，比如你遇到了GUI，比如你遇到了计时器（Timer）。敏捷并非教条，当某些事不可为的时候，你完全可以不那么坚持。于是，你告诉自己，不好测的东西可以不测，这样，至少从心理上来说，你觉得舒服多了。随着工作的继续，你发现，你不能测的东西越来越多，单元测试的覆盖率随着开发的进行正在逐渐降低，一丝恐惧涌上心头。回过头来，再去看Kent Beck的书，你突然觉得，你似乎被骗了，因为Kent Beck的例子貌似全都是逻辑，如果只是逻辑，当然好测了，但现实从来就不是这样。
难道TDD只是看上去很美？
显然，你不愿意就这样放弃，放弃你苦心学来的软件开发秘籍，那些传说中的高手极力推崇的TDD必然有一定道理，TDD确实能够让你感觉很好：能测试的那部分代码确实极大的增强了你对软件质量的信心，而且出错了也确实好找，每次修改代码之后运行测试出现的绿条也确实让你身心愉悦。
那问题到底出在哪呢？你陷入了沉思。
信马由缰，你翻开了自己写过的代码。看着自己写的这些代码，你忽然意识到一个问题，自己遇到的问题并不属于TDD，而是属于单元测试。正如你之前所想到的那样，TDD做法本身的结果是让你感到快乐的。对，一定是单元测试本身出了问题。那单元测试出了什么问题，很显然，一大堆不能测试的部分让单元测试变得很难写，降低了单元测试的覆盖度。那是不是这会是一个无解的问题呢？你显然不愿意就此放弃，所以，顺着这个思路继续向前。
文章来源于领测软件测试网 https://www.ltesting.net/