反正当时是写得我直接摔了鼠标！写得憋屈啊！而且我还是完全隔绝了数据库的，真不知道那些要从数据库里取数据来跑单元测试的，是怎么做的？这时候我一下子明白了，实际工作中加班赶进度，一个接一个的填坑，连重构的时间都没有，怎么可能还挤得出时间来写单元测试？算开始雄心勃勃的写了，随着系统日益复杂，维护单元测试的成本也与日俱增，甚至复杂度更甚开发，所以放弃也成了绝大多数项目的选择。
　　在公司上班么，大多数人都是这样的，能推推。我们开发写完了代码，基本上能跑了，该交给测试人员了呀！天经地义的嘛，是不是？而且测试的时间是不会计算到我的项目开发时间里的，我总算是按时完成了开发任务。累坏了，休息一下，让测试的忙活去吧，哈哈……
　　但我是个光杆司令，我没测试人员啊！曾经有那么一两个时候，我真准备招一两个测试人员的。但好在我天生的节俭美德（也是“抠”啦）让我冷静下来。我想啊：测试只能告诉你出了bug，不能告诉你根源啊。没有单元测试，我单步调试，不也折腾了两天了么？这是系统本身的复杂性，或者代码组织的不合理造成的，不能归咎于单元测试。不还是有这么多开源代码都有详尽的单元测试么？他们是怎么做到的呢？在单元测试上的付出，终一定会获得超值回报！想想没有单元测试的公司，那超级庞大的测试团队，或者四处冒烟的系统，你愿意走这么一条路么？
　　所以我不断的告诫自己，不要着急，冷静细致。终于一步步抽丝剥茧，把这一团乱麻一点点的归纳整理，终还真被我找到了一条路子，一个个的单元测试都慢慢完成通过了，开发代码里潜在的一些问题也浮出水面，被我一个个的消灭。后再跑一遍单元测试，一路绿灯，哈哈！更奇迹的是，困扰我两天的bug不知道什么时候消失了？
　　后来，我看到这样一种说法：可测试的代码不一定是好代码，但坏代码几乎是不可能被测试的。深以为然！深度耦合的代码，写他们的单元测试，难于上青天；但反过来，我们可以以可测试为标准，不断的完善重构开发代码，只要这样坚持下来，终代码的质量怎么都不会差到哪里去。
　　所以，于我而言，单元测试是否有价值的争论可以休矣！不如换个角度，想一想，怎样才能把单元测试坚持下去。
　　后，如果有心的同学会注意到，我一直用的是“单元测试”，而不是“测试驱动”。因为测试驱动是一个更广阔的概念，是一个更崭新的天地！单元测试只是其中的一小部分，在下一篇博客，我会讲解我是如何试着将测试驱动的概念运用到项目开发管理中去的。这里，需要强调的一点：先写测试。
　　一上手写开发代码，写完了才写单元测试。这是很多开发人员的习惯，我也经常犯这样的毛病，一不留神忘了。这样做大的问题是，没有真正实现“测试驱动”。你实际上还是由开发在驱动，那么很自然的，测试照着开发的if…else…写一遍，有什么意义呢？这样做下去，会不断的强化“测试无用累赘”的印象，因为测试是简单的把开发代码重写一遍而已。我开的药方是：
　　单元测试代码和开发代码由不同的人员编写
　　如果做不到上面一点，先写单元测试
　　如果连上面一点也做不到，直到出了bug了再写单元测试
　　第三条可能有同学无法理解，不是说单元测试很重要么？为什么要等到出了bug才写？答案是：偷懒呗！记住，我们程序员是世界上懒的人，没意义的事从来不做！你先写开发代码再写测试真的没意义，没意义干脆不要做了。但你可以开启“乐观模式”（或者“Lazy模式”？），先乐观的认为，我的代码没问题，或许真的没问题呢，是吧？如果真出了问题，做一个补救，这个时候应该用单元测试把这个问题表现出来，因为他根据墨菲定律，它这里出了问题，以后很有可能继续出问题。这个时候，不要再偷懒了。