又是老生常谈-'单元测试'，说实话自己在单元测试上是'语言上的巨人，行动上的矮子'，属于那种说的比做的多的人^_^。不过也不能说什么也没做。记得去年年末的时候自己还设计并实现过一个简单的'C语言单元测试包'呢^_^，至今这个包仍然还在使用呢。不过大多数的单元测试都不像想象中那样简单，我们在介绍单元测试的时候，大多拿Add、Sub等作例子，这样当然有好处，简单易懂。其实学习单元测试初期关键是学习单元测试的思想，所以这些Add、Sub也能满足需求。不过在真正的项目中，单元测试大多做起来较为困难，我是在Unix上做C开发的，Java的咱暂先不提，也没什么资格提，虽然曾经花过一段时间专心研究过，还写过些Java学习心得，但是毕竟没做过实际的项目，说起来心里也发虚。

曾经很长一段时间，自己在编码阶段基本上都是缺少单元测试的，一是项目中Legacy代码较多，耦合太紧，想把那部分代码拿出来比'登天还难'(有点夸张)，反正基本上是'一扯一大帮'，俗称'一个都不能少'；而是部门在这方面积淀较少，在计划的时候对这方面考虑不够，时间上也不充裕，经常是在集成测试或者系统测试的时候顺便带上单元测试了，这样的后果就是'浪费'。本来在单元测试阶段发现一个Bug需要10 minutes，拖到集成测试或者系统测试后，这个时间就可能是1 hour或者 1 day 或者更多时间，这里可不是'耸人听闻'，的确有真实的事例，有过这样的经历的人都体会到其中的痛苦。

痛定思痛，自己终于觉醒了。恰好，一个新的短期项目刚刚处于开发阶段，正好是发挥单元测试的大好时机。杀开一条血路，做就是了。但是不能盲目去做。单元测试是需要设计的，而且感觉单元测试设计因系统架构模式而异，有难有易；而且单元测试设计时需要考虑项目进度、测粒度和测试密度。测试粒度，也就是说你选择多大的功能单元来作为单元测试的基本单元，是函数一级的还是模块一级的；测试密度，则是你的单元测试用例的语句覆盖度有多少了。完美的单元测试是应该覆盖程序运行的每条分支的，但是要编写出这么多的单元测试用例，其工作量我想比开发这个系统的工作量只多不少，这样一来即使你能编写出这么多用例的代码，你的Leader也会对你吼的。选择关键路径覆盖是我的选择测试密度的'标准'。我们的系统的架构是基于'队列/管道架构模式'的，这也决定了我们的单元测试较容易，根据这个特点我选择我的单元测试的力度是模块一级的。基本策略就是根据模块内的关键路径设计模块级别的单元测试用例–对我们这个系统来说具体就是造各种各样的消息，放到输入队列中即可。

我的单元测试已经进行了两天多了，效果很是明显，有些bug的发现都出乎我的意料。每当测试完一个功能模块，我会感觉对这个模块更有信心了，还有一种莫名的成就感^_^。

好的单元测试最好是能自动化，这样一旦修改了代码，可以对以前测试过的代码进行回归单元测试，保证此次修改不影响到以前已经测试过的代码的正确性。不过自动化又谈何容易？Java有很好的工具支持，可谓众星捧月；C则是孤家寡人，少有有利的工具支持。这样的话，我们就需要自己写自动化的逻辑，当然这些逻辑因系统而异，至今我也很难想出好的通用的办法，比如像Mock Test这样的测试，在C中就很难实现，我们常常以真实的情景代之，而不是使用Mock，这样就可能让不同的用例对执行顺序有一个依赖，执行顺序不一致，测试的结果可能不相同。

以上的一些经验都有一定的语言局限性，对于使用C开发的系统可能有些借鉴的意义，但是对于Java开发的系统上面的很多说法也许还是误导的，大家一定要'睁大眼睛'，看清楚了^_^。单元测试仍在进行中…^_^

发现静寂的夜能让我的思维加快。

用Mock Object进行Unit Test已经一周多了，发现以前对Mock Object还是很肤浅，即使是现在我也不敢说我对Mock Object的理解就一定正确。

这篇blog假设你已经熟悉JUnit、了解Mock和TDD。
如果你是直接开始使用JMock 、Easy Mock或者是MockMaker等Mock Object框架的，我建议你简单了解一下Mock Object的演化历史，这样你在使用Mock Object时才会更有的放矢。

Mock object有关键的两个概念：
* 建立起环境的概念。在www.mockobjects.com的faq中有一句是这样叙述的“I think the fundamental thing to remember about Mock objects is that they are just that – simple shells or placeholders.” Mock object只是替代了被测Object环境的代码。
* test assertions被隐藏在Mock object内部实现中了，在你的test case中用来verify被测代码与Mock object的交互。

在单元测试中，人们发现有一些问题（这些问题在我的“认识Mock Object”中已列出）常见单元测试工具（如JUnit）并不能很好、很便捷的解决，这样Mock object被引入来解决这些问题。

最初人们手工编写Mock Object。随着测试问题越来越复杂，人们自己手工编写的Mock object越来越多，人们开始将编写Mock Object过程中一些通用的东西抽象出来，形成了一些Mock Object Lib，以帮助开发人员快速得到自己需要的Mock Objects。

当前的Mock Object Lib有多种，大致可分为两类：
* Static Mock Objects Lib
* Dynamic Mock Objects Lib

这里简单举例说明一下不同类型Mock object lib的使用方法，并与手工编写进行对比。

问题：我们在测试某个class时，我们需要与MyInterface这个接口进行交互，而该接口尚未实现，这时我们使用Mock object来替代。

接口MyInterface:
public interface MyInterface {
    public SomeClass getSomething();
    public void setSomething(SomeClass aSomething)
        // Other methods omitted…
}

* 手工编写mock object:
public class HandcraftMockMyInterface implements MyInterface {
    public SomeClass getSomething() {
        return something;
    }
    public void setSomething(SomeClass aSomething){
        this.someting = aSomething;
    }
    private SomeClass something;
    //others
}

* 使用Static Mock Object Lib编写Mock Interface：
public class StaticMockMyInterface extends MockObject implements MyInterface{
    private final ExpectationValue something = new ExpectationValue("something");  
    public void setSomething(SomeClass something){
        this.something.setActual(something);
    }
    public void setExpectedSomething(SomeClass something){
        this.something.setExpected(something);
    }
    public void SomeClass getSomething(){
        return this. something;
    }  
}

* 使用Dynamic Mock Object Lib编写Mock Interface：(以JMock为例)
Mock dynamicMockMyInterface = new Mock(MyInterface.class);
MyInterface mi = (MyInterface) dynamicMockMyInterface.proxy();

SomeClass someThing = new SomeClass();
dynamicMockMyInterface.expects(once()).method(“setSomething”).with(eq(someThing));
dynamicMockMyInterface.expects(once()).method(“getSomething”).will(returnValue(someThing));

//执行你的测试代码,比如你的tested object与MyInterface mi交互的代码。

dynamicMockMyInterface.verify();

Mock Object的使用流程
- Setup any state — setup the fixture for your test
- Set expectations for the test
- Run the target code
- Verify that your expectations have been met

Mock Object Practical Experience
- 好的设计是容易测试的设计
- 尽量让测试在内存中完成，不要在硬盘上留下“垃圾”
- 面向接口使用Mock Object。better to implement interface , not inherit class