大家都在用什么mocking framework?

乱码

我们在用rhino mock, 80%算是说的过去

但对non-virtual methods,static methods还是要work around，否则写出来的东西很难看--不明不白的加些virtual，或者interface满天飞，或者避免用static class.

现在想选一个其他的framework,能在上面的方向满足我们的要求。

看了一下，好象这两个还行。

http://www.telerik.com/products/mocking.aspx

http://www.typemock.com/

但都不是免费的.

好像moles也不错，貌似免费的。

http://research.microsoft.com/en-us/projects/moles/

大家都在用什么？

[ 本帖最后由 乱码 于 2011-7-21 19:00 编辑 ]

atransformer

http://stackoverflow.com/questio ... ng-framework-to-use

乱码

原帖由 atransformer 于 2011-7-21 21:48 发表
http://stackoverflow.com/questio ... ng-framework-to-use

谢谢兄弟，分分回来了给你加！

bubblecry

moq

atransformer

原帖由 乱码 于 2011-7-21 22:14 发表


谢谢兄弟，分分回来了给你加！

分分的，无所谓。我是跟着你们后面捡技术的。

linkspeed

这个mock实在太搞了，1个礼拜了脑子才有点拐回来了。

为了测试，static也不能用了。
每个类都要弄个interface了。
web service也不能直接调用了。
appsetting也不能直接读了。

linkspeed

这个没问题
stubobj.Stub(x => x.ValidateModelFinal()).Return(false);
ValidateModelFinal（）不会被真实的调用，直接返回false

这个就不行了。它会真的去调用SetCurrentPage()
stubobj.Stub(x => x.MenuList.SetCurrentPage(Arg<string>.Is.Anything, Arg<int>.Is.Anything, Arg<string>.Is.Anything)).          Return("");

有没有办法不把MenuList也mock，然后防止真的调用SetCurrentPage()?

linkspeed

在x里面弄个一样名字的函数间接调用这种方法不算

乱码

原帖由 linkspeed 于 2011-8-3 16:56 发表
这个没问题
stubobj.Stub(x => x.ValidateModelFinal()).Return(false);
ValidateModelFinal（）不会被真实的调用，直接返回false

这个就不行了。它会真的去调用SetCurrentPage()
stubobj.Stub(x => x.MenuList.SetCurren ...

有ignorearguments么？

乱码

原帖由 linkspeed 于 2011-8-1 23:11 发表
这个mock实在太搞了，1个礼拜了脑子才有点拐回来了。

为了测试，static也不能用了。
每个类都要弄个interface了。
web service也不能直接调用了。
appsetting也不能直接读了。

static没所谓，有ioc container给你维护lifecycle，任何东西都是instance的，不过在ioc中定义你想做为static的class为singleton.

每个class都有interface还行啊，越多越好。

基本上都要通过interface干事，习惯就好了。

最要命的是sealed class不行，普通的method都要加virtual，要测的都要弄成public，或者有workaround，这比较烦。

[ 本帖最后由 乱码 于 2011-8-3 18:13 编辑 ]

linkspeed

今天突然想通了一点：

用mock来测试，是否意味着
object最好只调用和它直接联系的object的metho。
而不要去调用那个object的peroperty的method.

乱码

原帖由 linkspeed 于 2011-8-8 16:36 发表
今天突然想通了一点：

用mock来测试，是否意味着
object最好只调用和它直接联系的object的metho。
而不要去调用那个object的peroperty的method.

我没听懂

你要stub什么？别人的logic或者直接用的logic是需要stub的，自己的logic，可以mock，也可以直接assert,很多人喜欢verifyexpect，看你个人喜好。

又看了一遍，好像有点懂了，你只要stub一级method，mocking framework就会fake它，不用管下一级东西。

[ 本帖最后由 乱码 于 2011-8-8 18:28 编辑 ]

linkspeed

public methodA()
{
     this.ObjectA.MethodB();
     this.ObjectA.PropertyC.MethodD();
}

比如上面这个methodA(), MethodB可以生成stub,
但是MethodD()就没法直接生成了，除非我把PropertyC
也给stub了。

反过来想，就是尽量只搞1级调用，不要跨过去。

我记得以前java有个工具，专门是在上层类里面自动生成
内部属性的那些函数的，以避免出现 this.objecta.propertyb.propertyc.Methodone()这样的调用。

如果用那个工具，这个methodone就自动生成在objecta的类里面。
调用就变成 this.objecta.methodone();

乱码

原帖由 linkspeed 于 2011-8-8 17:42 发表
public methodA()
{
     this.ObjectA.MethodB();
     this.ObjectA.PropertyC.MethodD();
}

比如上面这个methodA(), MethodB可以生成stub,
但是MethodD()就没法直接生成了，除非我把PropertyC
也给stub了。

反过 ...

对，是这个意思，如果非得跨，把PropertyC也做成一个abstraction, inject进来，然后stub他的MethodD().

[ 本帖最后由 乱码 于 2011-8-8 18:33 编辑 ]

linkspeed

我理解了，这玩意就是逼你去考虑接口。
否则东改改西改改很快就不知道成啥样子了。

乱码

原帖由 linkspeed 于 2011-8-10 10:47 发表
我理解了，这玩意就是逼你去考虑接口。
否则东改改西改改很快就不知道成啥样子了。

嗯，盡量降低object graph複雜度，盡量扁平。

高層的business rule那邊盡量讓ioc管理OBJECTS，底層實在不能避免NeW也沒辦法。