手头的项目越来越大，很多以前不会出现的问题开始浮现。
比如：我修改了一个基础的类库，却意外的影响了九重天外的客户项目，直接导致一个功能无法实现。我郁闷啊！！！
因此开始要有组织、有预谋、有计划的对项目过程进行测试驱动了。最终目标是，我修改了底层某个dll的某个方法，测试框架能够自动帮我找出来所有收到影响的类，全部执行一次回归测试，并发送一份漂亮的报告到我手里。
这个目标估计1、2个星期才能实现，不过现在先放出一个非常漂亮的MOCK核心代码。
研究过程
在不断收集各种资料过程中，学习了很多，例如以下关键字，有兴趣的兄弟可以自己搜索一下：
testdriven.net, nunit, typemock, cruiseControl.net, Confluence, JIRE, NUnitForms, WatiN, MBUnit, CSUnit, NBehave, Gallio
ranorex, dynamicProxy...
估计各位有时间看看上面的简介，就能够掌握现在测试驱动的大致发展。
- nunit的核心代码非常容易理解，大伙自己下载看看就行了。
- testdriven.net 的前身是：NUnitAddin， 如果要研究如何testdriven集成到vs，看看不错。
- WatiN的核心代码虽然我没有看，不过猜也能猜到，就是调用了IE的核，然后搜索上面的html标签操作。
- typeMock有点混蛋，源码混淆了，无法拿到核心技术，不过从介绍来看是源自了castle.DynamicProxy，那么各位可以参观一下一篇非常垃圾的文章，但是起码让我入门了： http://www.cublog.cn/u/23701/showart_1414436.html
- 最后，我来到了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。下回再见。