抛弃教条主义，走出一条真正的

前言：

     测试，对于我一个程序爱好者来说，真正接触也就1年半。而真正感觉到测试的重要性和对测试开始有了思考也是最近才开始的事情。记得前年4月份的时候，我去了我们这面一家相对稍微可以一点的公司（西部地区，实力确实不能高估），第一次，项目经理要求我们给完了的代码写单元测试，当时我虽然不是第一次接触单元测试这个概念，却是第一次实打实的弄这玩意，但是整个过程，我感觉完全是为了应付测试部和QA（一方面，QA要查测试用例代码和报告，另一方面，没有经过单元测试的功能，测试部的人不测）。写的所有测试用例，我感觉就像脱掉裤子放屁，多此一举。因为那时候，我们是给我们这面的民政厅做一个业务系统，逻辑并不复杂，每个SERVICE无非就是稍微组合了一些复杂的查询而已。（这是我当时的感受）。

     后来，在那个项目基本上结束的时候，我离开了公司，去了学校继续学习。在学校期间，别人投资我搞一款网页游戏，这款网页游戏设计到了复杂的多线程操作（当时我实际项目开发经验就2年，基本上全部是MIS系统，虽然早在我去第一家公司做事的时候就知道了并发的问题，而且我从第一家公司辞职的原因也是因为所有功能设计的时候没有考虑到并发问题，我一时不知道怎么解决，而“逃跑”，其实对于那样的MIS系统，事务就已经把这一切解决掉了，可是我那个时候并不知道，因为我只知从表面知道事务这个东西不提交数据库不能修改，但是其他什么都不知道。但是我现在记不清了，为什么我在做民政那个项目的时候我似乎一度忘记了这个东西。），就这样，由于我经验匮乏，在做在程序的并发和互斥设计方面做出了许多错误的判断，而且我尽然直接抛起了测试，改为从UI进行手动测试（当时我就在想，写那么多测试代码我可没那个时间，完了手一点不就行了。），就那样，这个项目做了一年，核心慢慢稳定的时候，当要进行功能扩展的时候，我急眼了，那个时候可真所谓是牵一发而动全身呀，有时候我修改一个功能，要看很多很多代码，而且脑袋蹦的紧紧的，就害怕忘记什么，这样，坚持到原来的核心无法满足现有的功能扩展需求需要需该核心的时候，我彻底崩溃了，因为每修改一行代码，我对我的东西就绝望一次，一直到最后，发现核心由于互斥设计不合理而存在严重BUG的时候我彻彻底底的绝望了。因为真的无法修改下去了。。。用我的话来说就是“它彻底坏掉了”。后来我不得不回过头来开始重新构建，由于这次的阶段性失败，我不得不重视测试这个东西，我似乎一竿子把所有的问题都归咎于没有很好的测试代码。

     现在，我开始重构这个东西了（早在半年前，我正式决定看看TDD相关的东西，当时，我负责一个网站，在整个开发过程中，我试图强加TDD给开发的人，而说实话，那时我对测试代码依然相当反感，我只知道别人都说那是对的，但是自己心底里却不能真真切切的接受，其实也有种走形式的感觉），我决定亲自尝试一下TDD，我选择了极限开发的方式，作为入门，但是在进行测试用例编写的时候，我却又一次开始迷茫，开始徘徊，开始怀疑，测试这个东西真的能使我免受前面的那些失败吗？如何确定测试用例，测试用例对功能的覆盖率又如何把握呢？是心里想到哪里就写到哪里？还是不放过每一个角落的却编写测试用例？我发现，如果你想用测试用例来描述程序的每一种可能是那么的困难，终于，我不得不让自己停止手指的敲动，而给自己一点时间来思考。这时候有2句话浮现在了我的脑海中，一句是“测试能尽量减少我们程序的BUG”，另一句是“请拥抱变化”。

     这2句话给了我答案，测试，其实他并不能消灭所有BUG,它只能尽量的减少BUG ，一个经过了重重测试（单元测试，集成测试，系统测试，压力测试==）的好东东，谁敢说他没有BUG？而且，测试用例的规划和程序员本来的经验和素质有很大关系，从而也确定了测试的质量。我个人觉得在TDD中所有的测试用例，并不应该是