【问题标题】:Create object with name to inject into unit test创建具有名称的对象以注入单元测试
【发布时间】:2017-04-04 14:31:16
【问题描述】:

我正在对一个类进行单元测试,该类将工厂作为其依赖项之一,并使用它来构建 SUT 有效控制的对象:

class SystemUnderTest
{
    private readonly IFoo foo1;

    private readonly IFoo foo2;

    public SystemUnderTest(IFooFactory fooFactory)
    {
        this.foo1 = fooFactory.Build("Bar1");
        this.foo2 = fooFactory.Build("Bar2");
    }

    public IFoo Foo1
    {
        get 
        {
            return this.foo1;
        }
    }

    ...
}

SystemUnderTest 对象有一个单例生命周期,它被注入到多个 ViewModels 中,这些 ViewModels 使用它的属性/方法来执行不同的操作,因此这有效地排除了定义 Provider 类以便我可以注入 foo1foo2 没有与构造函数中的工厂接口,这是我在遇到这个问题时通常会做的事情。

但是通过注入工厂,我无法用AutoFixture 弄清楚如何正确配置fooFactory 以提供正确的IFoo 并将其作为方法参数传递给我的测试,例如:

[Theory]
[AutoData]
internal void Foo1_IsCorrectlyPopulated_Test(
    [Frozen] IFoo foo1,
    SystemUnderTest systemUnderTest)
{
    var actual = systemUnderTest.Foo1;

    Assert.Same(foo1, actual);
}

我知道我可以扩展 AutoData 属性并为 Fixture 提供我自己的自定义,例如:

class SystemUnderTestAutoDataAttribute : AutoDataAttribute
{
    public SystemUnderTestAutoData()
    {
        var fooFactory = this.Fixture.Freeze<IFooFactory>();
        var foo1 = this.Fixture.Create<IFoo>();

        Mock.Get(fooFactory).Setup(m => m.Build("Bar1")).Returns(foo1);
    }
}

但我想知道是否有能力获取我在属性构造函数中创建的foo1 对象并将其作为参数传递给测试方法?我知道我可以Freeze foo1 对象,但这意味着我需要为foo1foo2 提供两个属性类来为我的测试方法提供正确的信息,当我不得不这样做时,这会失败在我的测试用例中使用这两个对象。

我希望有一种方法可以创建具有特定名称(或其他匹配方法)的对象,并在测试用例中匹配它(不编译):

[Theory]
[SystemUnderTestAutoData]
internal void Foo1_IsCorrectlyPopulated_Test(
    [Frozen(Matching.CreationName)] IFoo foo1,
    SystemUnderTest systemUnderTest)
{
    ...
}

class SystemUnderTestAutoDataAttribute : AutoDataAttribute
{
    public SystemUnderTestAutoData()
    {
        var fooFactory = this.Fixture.Freeze<IFooFactory>();
        var foo1 = this.Fixture.Create<IFoo>(creationName: @"foo1");

        Mock.Get(fooFactory).Setup(m => m.Build("Bar1")).Returns(foo1);
    }
}

因此,任何具有名称(或其他匹配方法)的匹配注册实例都可以作为测试用例参数的一部分解析?

【问题讨论】:

    标签: c# unit-testing dependency-injection autofixture


    【解决方案1】:

    类似下面的东西应该可以工作。首先,像这样定义一个[AutoMoqData] 属性:

    public class AutoMoqDataAttribute : AutoDataAttribute
    {
        public AutoMoqDataAttribute()
            : base(new Fixture().Customize(new AutoMoqCustomization()))
        {
        }
    }
    

    其次,这样写你的测试:

    [Theory, AutoMoqData]
    public void MyTest([Frozen]Mock<IFooFactory> td, IFoo foo1, IFoo foo2, IFixture fixture)
    {
        td.Setup(f => f.Build("Bar1")).Returns(foo1);
        td.Setup(f => f.Build("Bar2")).Returns(foo2);
        var sut = fixture.Create<SystemUnderTest>();
    
        // Rest of test...
    }
    

    也就是说,使用工厂来处理生命周期问题几乎总是一种设计味道。 OP 中的特定设计违反了Nikola Malovic's 4th law of IoC。考虑将对象的设计与其生命周期管理分开。一种方法是使用Decoraptor

    【讨论】:

    • 谢谢 Mark 我认为这可能是最简单的方法,但我想看看是否有一些东西可以在测试中不必手动创建 SUT,但这很好。在设计方面,我知道这是一种气味,但我很难看到Decoraptor 在这种情况下会如何提供帮助,因为我的Client (ViewModel)Service 都有效地具有单例生命周期,因为在我的情况下是服务存储状态,每当访问此状态时,每次都需要重建服务?
    • @StephenRoss 这是一个新问题 ;)
    猜你喜欢
    • 2017-12-11
    • 1970-01-01
    • 1970-01-01
    • 2010-12-16
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多