测试中的犀牛

　　最近，把我的 DbEntry 的客户端源码控制改成了 VisualSvn + SvnBridge 的方式，感觉这种非独占方式 check-out 很适合广域网用户，只是 SvnBridge 还有一些不完善，于是，下载了它的源码版本，自己编译，在最近一次比较大的 check-in 之后，另一台机器执行 update 总是不成功，于是再去下载最新的 SvnBridge 源码，也没有效果，最后重新 check-out 反而成功，也许是服务器超时造成的？

　　在浏览 SvnBridge 的压缩包的时候，发现了它是使用 xunit 进行单元测试的，这个听说过，据说是原 nunit 作者的新作，利用了更多的 .net 的语言特性，应该是更好用的吧；另外，发现了一个奇怪的 dll 名：Rhino.Mocks.dll。Rhino 我记得是一个 Java 实现的 JavaScript 引擎，不过，Rhino.Mocks 是什么鬼？

　　搜索 Rhino.Mocks，发现几篇介绍的文章，原来是一个 mock 框架，和那个 JavaScript 引擎没什么关系。

　　以前一直都是直接手写 Mock 类的，对于 Mock 框架没有什么认识，最近因为工作的关系，接触到 MockLib ，发觉对于一些复杂的接口，用 Mock 框架确实可以减少一些重复劳动。

　　在介绍的文章 Rhino.Mocks 中，有 一篇 介绍的挺好的，做了 EasyMock，JMock，NMock， NMock2 和 Rhino.Mocks 的比较，很不错。文中介绍 Rhino 做 Record 的语法如下：

subMock.Receive(message);
Expect.On(subMock).Call(subMock.MultiplyTwo(5)).Return(10);
mocks.ReplayAll();

　　无返回值的函数语法简直太自然了！这里，因为不是使用字符串来描述函数名，所以，有智能提示，有编译时运行检查，也支持重构工具，非常棒。不过，既然这种“Record/Replay”模型这么自然，而另外那种“Expectation”模型也依然存在，可能说明，这种方式还是有一些特殊的地方，不如“Expectation”模型吧。

　　看着，突然想到 .net 3.5 的 expression tree，这种延迟运算方式如果运用于“Expectation”模型应该也可以，而且，同样可以取得“Record/Replay”模型的智能提示、编译时运行检查、支持重构工具等特性，简直太完美了！

　　不管怎样，先去下载 Rhino Mocks 再说。到了它的下载页，赫然发现 Rhino Mocks 3.5 Beta - For .Net 3.5 的字样，哈，看来他应该比我早想到这个主意了吧 ：D

　　再次搜索 Rhino Mocks 3.5，发现了 一篇介绍的文章，语法上比我想象的复杂一些，不过还是很酷，回头研究一下，或许就使用到项目中去吧。