【IT168 谈论】这几年了陆陆续续的学习过不少技能，但真实能够对自己的作业起很好协助的是在不多，测验驱动是其中之一。前段时刻国外的有位程序员Karl Seguin收拾了一篇文章叫The 7 Phases of Unit Testing ，很快在译言网上也有了翻译《单元测验的七种境地》，作为一位测验驱动开发的粉丝也像借这篇文章收拾一下自己的学习进程和体会

　　1. 以各种托言回绝单元测验Unit Test，比较常用的是“你没有满足的时刻(进行单元测验)”。

　　无论是对单元测验的内行仍是新手编写单元测验仍是有必定得作业量的，而且单元测验也需求把握许多的测验结构和东西(光一个junit或testng你很难作业地很happy)。所以在这个阶段开发人员往往会觉得单元测验很难写、很费时，自然而然会运用没有满足的时刻(进行单元测验)的托言，其实在这个阶段开发人员需求积极地学习和把握测验结构和了解单元测验理念。

　　2. 测验单元测验而且马上开端在自己的博客商宣扬单元测验和测验驱动开发Test Driven Development的优点。

　　开发人员在这个阶段学习很把握了一些单元测验的东西并在实践作业中加以的运用，并很好的处理了一些问题，认识到了单元测验的价值。我自己也向搭档和同学介绍过相关的技能，期望我们对相关的技能能很好的学习和运用，现在回想那个时候对单元测验的技能的把握和了解都是不完整的，只能说是初窥门径罢了。

　　3. 单元测验全部。为了能够完结单元测验，而将私有private的办法和特点修改为内部internal;为了到达单元测验覆盖率100%而测验getter() 和 setter() 特点(办法)。

　　这样的阶段很明显，特别是遇到private，static办法的测验时会感到很费事，所以往往采用了一些不美丽的处理办法，意图是能够对相关的办法和类进行单元测验，但没有从根本上认识到是自己的规划有问题，然后导致可测验比较差(testability)。至于对getter和setter 办法进行测验到是没有过，或许只自己地点的公司一向都没有片面的强调过测验100%覆盖率吧。

　　单元测验也是代码，只要是代码就会有规划、编码上一同的问题，比方规划形式的运用、重复代码的问题。在无法了解和单元测验中“单元”和“阻隔”这两个名词的状况下，会想要经过集成测验来完成单元测验。我自己没有运用过集成测验的东西，但用dbunit直接模仿数据库的状况，然后将多个类“集成”起来测验是这个阶段最常用的单元测验办法。实践上用dbunit直接模仿数据库也是十分软弱和繁琐的，mocking才是王道。

　　mocking是单元测验中不行短少的重要组成，Java的单元测验计划中Easymock和Jmock是两个老练的Mock结构。但 Mocking的学习和了解或许是单元测验东西中最具有难度的当地了，经过运用Mocking你会发觉之前许多作业(比方数据库模仿)都是浪费时刻、精力和无效的。

　　经过在单元测验中运用Mocking真实遵循了单元测验的“单元”和“阻隔”的准则，不过Mocking是在件繁琐和困难的工作，这时候就需求考虑什么是必需要mock的、什么能够不mock的。

　　祝贺你总算到达了这个阶段，你现已将面向对象规划、规划形式、单元测验、重构等一些技能都融汇到了一同，你总算能够依据自己的志愿编写真实有用的单元测验了。在这个阶段或许你把握或有了一套测验结构，这套测验结构整合了junit、testng、jmock、easymock、dbunit、xumlunit、unitils等一系列你测验东西使你的编写单元测验功率是之前的3-4倍或许更多。