初学测试驱动的MOCK技术，展示一下牛逼的成果！

前言

手头的项目越来越大，很多以前不会出现的问题开始浮现。

比如：我修改了一个基础的类库，却意外的影响了九重天外的客户项目，直接导致一个功能无法实现。我郁闷啊！！！

因此开始要有组织、有预谋、有计划的对项目过程进行测试驱动了。最终目标是，我修改了底层某个dll的某个方法，测试框架能够自动帮我找出来所有收到影响的类，全部执行一次回归测试，并发送一份漂亮的报告到我手里。

这个目标估计1、2个星期才能实现，不过现在先放出一个非常漂亮的MOCK核心代码。 

研究过程

在不断收集各种资料过程中，学习了很多，例如以下关键字，有兴趣的兄弟可以自己搜索一下：

testdriven.net, nunit,  typemock, cruiseControl.net, Confluence, JIRE, NUnitForms, WatiN, MBUnit, CSUnit, NBehave, Gallio

ranorex,  dynamicProxy...

估计各位有时间看看上面的简介，就能够掌握现在测试驱动的大致发展。

1. nunit的核心代码非常容易理解，大伙自己下载看看就行了。
2. testdriven.net 的前身是：NUnitAddin， 如果要研究如何testdriven集成到vs，看看不错。
3. WatiN的核心代码虽然我没有看，不过猜也能猜到，就是调用了IE的核，然后搜索上面的html标签操作。
4. typeMock有点混蛋，源码混淆了，无法拿到核心技术，不过从介绍来看是源自了castle.DynamicProxy，那么各位可以参观一下一篇非常垃圾的文章，但是起码让我入门了： http://www.cublog.cn/u/23701/showart_1414436.html
5. 最后，我来到了Moq，开始因为听说是.net3.5，就没有看源码，不过刚才研究了一下顿时非常兴奋。起码Moq能让我解决了50%的工作。

接下来就说下Mock技术和测试驱动中的作用。

Mock技术 

我最不喜欢老外造名词，所以会用自己的体会去介绍。

mock的本质就是模拟目标对象的一个假对象。 

这个性质在测试驱动中非常有用，例如我的代码是：

        public DateTime GetNextFiredDate(DateTime now, IOrmScheduleTrigger trigger, int triggeredtimes)
        {
            return GetNextFiredDate(now, trigger.TriggerType, trigger.TriggerExpression, triggeredtimes);
        }

 现在要测试这个代码，就需要传入一个IOrmScheduleTrrigger的接口对象。但是不幸的是，这个对象是个ORM，要启动这个对象，就涉及到了数据库。。。。

老大，我只是想测试一下一辆宝马的玻璃是否坚硬，不需要启动我的宝马加速到120km，然后再用手去翘翘那块玻璃吧。

所以，我希望能够有个模拟对象，继承了这个接口， 同时提供了我期望的返回值，让这个方法能够顺利执行。

传统的傻逼方法，就是自己写一个类，继承了这个接口，然后才传入进去。例如：

public class OrmScheduleTriggerTestObject : IOrmScheduleTrigger
{
// some method here
}

这样不就更加的傻逼了？我为了测一块玻璃，还亲自造了另外一台简易的宝马出来？ 于是我开始翻阅各种文献，甚至考虑使用动态代理（DynamicProxy）。动态代理的核心思想就是在代码运行中写IL生成一个继承类。这个技术很有用，但是现在我还用不上（就像martin fowler说的，typemock就等于把核武器交给了一个4岁小孩）。

于是我继续寻找，终于翻开了Moq的源码，找到了答案。

先看看以下一段代码，是我摘自Moq源码的核心部分，稍加改造了：

using System;
using System.Collections.Generic;
using System.Text;
using System.Runtime.Remoting.Proxies;
using System.Runtime.Remoting.Messaging;

namespace Pixysoft.Framework.TestDrivens
{
    public class Mock<TInterface> : RealProxy
    {
        public Mock()
            : base(typeof(TInterface))
        {
        }

        public TInterface Value
        {
            get
            {
                return (TInterface)this.GetTransparentProxy();
            }
        }

        public override IMessage Invoke(IMessage msg)
        {
            IMethodCallMessage methodCall = msg as IMethodCallMessage;

            //我返回int = 1

            return new ReturnMessage(1, null, 0, null, methodCall);
        }
    }

    public interface IMock
    {
        int Devide(int a, int b);
    }

    public class testrealproxy //测试代码在这里！！！
    {
        public void test()
        {
            IMock mock = new Mock<IMock>().Value;

            Console.WriteLine(mock.Devide(1, 2));

            //输出 = 1
        }
    }
}

这段代码就是Moq的核心思想。

大概意思是：我希望调用接口IMock的方法Devide，但是我压根不想写这个接口的实现。

那么我先写一个通用的模拟对象Mock<TInterface>，继承了RealProxy。

然后通过调用Value就可以返回需要的接口对象。而这个对象就是 return (TInterface)this.GetTransparentProxy();是个透明代理。

最后当我调用了 int Devide(int a, int b); 方法的时候，等于调用了public override IMessage Invoke(IMessage msg)方法（有点点的AOP感觉）。

后记

上文就是Moq的核心思想了。非常的精彩！估计有了思路，各位就可以制造自己的原子弹了。

这里插句题外话，很多人抨击重复造轮子。我就奇怪了。如果我造一个轮子花费的时间和学习用一个轮子的时间差不远，为什么不造一个？

而且，用别人的轮子，经常出现的情况是：很多轮子不知道挑哪个。一旦挑上了，项目进展到一般才发现不适合、有bug，于是又重头挑另外的轮子。

这个经历是真实的。当年读大学，我的室友就是典型的挑轮子，他懂得很多框架（java），webwork，hibernate, spring。和人砍起来朗朗上口，但是需要深入做项目了，出现问题基本上不知所措，不是翻文献，就是问师兄，最后整个项目组从来就没有一个成品。

我自从学电脑依赖，从来就没有用过别人的轮子，即使是hibernate，我的确也没有用过，不过他的核心文档倒是看过，对比之下，和oracle的toplink相比简直就是小孩。

比我牛逼的兄弟大有人在，希望各位牛人不要浪费自己的时间去挑别人的轮子，直接自己造一个算了。 

最后说说接下来的工作。

基于接口的测试驱动完成了，剩下的就是面对sealed class 等顽固分子了， 必然需要动用非常规武器，DynamicProxy。下回再见。