手头的项目越来越大,很多以前不会出现的问题开始浮现。
比如:我修改了一个基础的类库,却意外的影响了九重天外的客户项目,直接导致一个功能无法实现。我郁闷啊!!!
因此开始要有组织、有预谋、有计划的对项目过程进行测试驱动了。最终目标是,我修改了底层某个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。下回再见。