菜鸟要作架构师（三）——单元测试的七种境界

软件开发离不开测试，而与开发人员关系最密切的当属单元测试了。别看单元测试只是整个软件测试学科的一部分，可是他里面的学问也很多，今天就跟你们分享一下，单元测试的七种境界。

1，以各类借口拒绝单元测试Unit Test，比较经常使用的是“你没有足够的时间（进行单元测试）”。

不管是对单元测试的老手仍是新手编写单元测试仍是有必定得工做量的，并且单元测试也须要掌握大量的测试框架和工具（光一个junit或testng你很难工做地很happy）。因此在这个阶段开发人员每每会以为单元测试很难写、很费时，天然而然会使用没有足够的时间（进行单元测试）的借口，其实在这个阶段开发人员须要积极地学习和掌握测试框架和理解单元测试理念。

2，尝试单元测试而且马上开始在本身的博客商鼓吹单元测试和测试驱动开发Test Driven Development的好处。

开发人员在这个阶段学习很掌握了一些单元测试的工具并在实际工做中加以的运用，并很好的解决了一些问题，意识到了单元测试的价值。我本身也向同事和同窗介绍过相关的技术，但愿你们对相关的技术能很好的学习和运用，如今回想那个时候对单元测试的技术的掌握和理解都是不完整的，只能说是初窥门径而已。

3，单元测试一切。为了可以完成单元测试，而将私有private的方法和属性修改成内部internal；为了达到单元测试覆盖率100%而测试getter() 和 setter() 属性（方法）。

这样的阶段很明显，特别是遇到private，static方法的测试时会感到很麻烦，因此每每采用了一些不优美的解决方式，目的是可以对相关的方法和类进行单元测试，但没有从根本上意识到是本身的设计有问题，从而致使可测试比较差（testability）。至于对getter和setter方法进行测试到是没有过，可能只本身所在的公司一直都没有片面的强调过测试100%覆盖率吧。

4，没法忍受脆弱的单元测试，在没有弄明白是什么的时候，就匆忙转向“集成测试"。

单元测试也是代码，只要是代码就会有设计、编码上共同的问题，好比设计模式的运用、重复代码的问题。在没法理解和单元测试中“单元”和“隔离”这两个名词的状况下，会想要经过集成测试来实现单元测试。我本身没有运用过集成测试的工具，但用dbunit直接模拟数据库的状况，从而将多个类“集成”起来测试是这个阶段最经常使用的单元测试方法。实际上用dbunit直接模拟数据库也是很是脆弱和繁琐的，mocking才是王道。

5，发现了一种模拟 mocking 框架，而且乐于使用强制语义（strict semantics）。

mocking是单元测试中不可缺乏的重要组成，Java的单元测试方案中Easymock和Jmock是两个成熟的Mock框架。但Mocking的学习和理解多是单元测试工具中最具备难度的地方了，经过运用Mocking你会发觉以前不少工做（好比数据库模拟）都是浪费时间、精力和无效的。

6，模拟mock全部可能模拟mocked的对象。

经过在单元测试中运用Mocking真正贯彻了单元测试的“单元”和“隔离”的原则，不过Mocking是在件繁琐和困难的事情，这时候就须要考虑什么是必需要mock的、什么能够不mock的。

7，开始真正有效单元测试。

恭喜你终于达到了这个阶段，你已经将面向对象设计、设计模式、单元测试、重构等一些技术都融汇到了一块儿，你终于能够根据本身的意愿编写真正有效的单元测试了。在这个阶段可能你掌握或有了一套测试框架，这套测试框架整合了junit、testng、jmock、easymock、dbunit、xumlunit、unitils等一系列你测试工具使你的编写单元测试效率是以前的3-4倍或者更多。

七种境界，层层递进、层层深刻，从形式主义到将单元测试真正的应用到工做中，这也是咱们从一开始接触单元测试，到慢慢熟悉、到深刻理解、到灵活运用的一个天然过程。大家如今都处在哪一个阶段呢？请本身找位置坐吧~~