嘲讽Autofac的“决心”扩展与TypeMock

我试图嘲弄的Autofac解决方法，如嘲讽Autofac的“决心”扩展与TypeMock

using System; 
using Autofac; 
using TypeMock.ArrangeActAssert; 

class Program 
{ 
    static void Main(string[] args) 
    { 
     var inst = Isolate.Fake.Instance<IContainer>(); 
     Isolate.Fake.StaticMethods(typeof(ResolutionExtensions), Members.ReturnNulls); 
     Isolate.WhenCalled(() => inst.Resolve<IRubber>()).WillReturn(new BubbleGum()); 
     Console.Out.WriteLine(inst.Resolve<IRubber>()); 
    } 
} 

public interface IRubber 
{} 

public class BubbleGum : IRubber 
{}

从起订量的到来，从TypeMock语法和异常迷惑了我很多。最初在TestMethod中运行它后，我不断得到一个异常，类似于“WhenCalled无法在没有补充行为的情况下运行”。我尝试为每个人和他们的母亲定义行为，但无济于事。

然后我调试通过测试运行，看到一个实际的例外是从Autofac发起的：IRubber尚未注册。

所以很明显，静态的Resolve函数并没有被伪造，我不能让它被伪造，不管我怎么去钩住它。

Isolate.WhenCalled(() => ResolutionExtensions.Resolve<IRubber>(null)).WillReturn(new BubbleGum());

...从Autofac引发异常，抱怨IComponentContext不能为null。喂它大概假冒的IContainer（或伪造IComponentContext代替）让我回到“IRubber未注册”的错误。

来源

2010-05-01 Lockshopr

这可能是逆潮流游泳的一种情况 - 创建“真实”容器所需的代码量以及相应的依赖项已注册，与TypeMock的配置较少或相似。我建议沿着这条路走下去。

除了目标组件完全依赖IContainer之外，您可以改为使用像Func这样的“关系类型”，除了易于模拟以外，它还隐含支持Autofac和更具表现力。 http://nblumhardt.com/2010/01/the-relationship-zoo/有关于该方法的更多信息，与http://code.google.com/p/autofac/wiki/DelegateFactories一样。

来源

2010-05-27 21:53:04

虽然你会如何模仿拥有？ – 2011-09-08 17:52:54

当你需要的时候，可以把'拥有的'看作是'List '或'string'这样的基本类型 - 使用它的构造函数构造'拥有的'的值，可能传递一个' T'实例。希望这可以帮助。 – 2011-09-08 20:36:37

对于拥有的类的lifeTime ctor参数，仅通过IDisposable的模拟是否正确？那个参数应该真正的通过什么？谢谢！ – 2011-09-15 14:51:12

嘲讽Autofac的“决心”扩展与TypeMock

回答

相关问题