【问题标题】:AutoFixture and private propertiesAutoFixture 和私有属性
【发布时间】:2014-03-28 08:12:14
【问题描述】:

我可以指示AutoFixture 也填充所有类的私有属性,并使用特定属性(例如Ninject.Inject)进行注释吗?源似乎只扫描公共属性:1。此问题为具有私有设置器的特定 MyClass 提供了解决方案,但不适用于私有财产或所有类:2

我正在使用 Moq 来模拟服务,最后我想用这些模拟来填充属性。如果我将 MyService 依赖项公开为 public,则以下设置可以正常工作。

一些示例代码:

public class MyController {
    [Inject]
    private IMyService MyService { get; set; }

    public void AMethodUsingMyService() {
        MyService.DoSomething();
        // ...
    }

    // ...
}

public class MyService : IMyService {
    public void DoSomething()
    {
        // ...
    }

    // ...
}

public class MyControllerTest {
    [Theory]
    [AutoMoqData]
    public void MyTest(MyController controller) {
        controller.AMethodUsingMyService();
    }
}

【问题讨论】:

  • NB Ninject 2 或更高版本不支持注入privates(它不应该在“马克的回答”中涵盖)。真的真的不要那样做
  • 我使用的是 3.0.1.10 版本并且注入 privates 工作正常,只要您指示 Ninject 注入它们 (InjectNonPublic)。我同意马克的回答!
  • 该死的以为这个选项在 V2 reimpl 中也死了,但我坚持纠正。这意味着文档是错误的(它说当我上次查看并在 2 年前使事情保持一致时,在很多地方都从 V2 中删除了注入私人信息)。遗憾的是,我无法激励自己在 wiki 中修复这些案例 - 希望其他人可以。

标签: c# autofixture


【解决方案1】:

AutoFixture 没有内置支持将值分配给非公共字段或属性。这是设计使然。

AutoFixture 是一个用于单元测试的实用程序库,以及单元测试shouldn't directly invoke private membersSUT

AutoFixture 最初是作为测试驱动开发 (TDD) 的工具而构建的,而 TDD 就是关于反馈的。本着GOOS 的精神,你应该听你的测试。如果测试很难编写,您应该考虑您的 API 设计。 AutoFixture 倾向于放大这种反馈,所以我的第一反应是挑战想要这样做的动机。

由于您引用的是 NInject,因此您看起来好像在使用依赖注入 (DI)。然而,带有私有属性注入的 DI 听起来很奇特。考虑将属性公开,甚至更好,使用构造函数注入而不是属性注入。

这将使 AutoFixture 像 Auto-Mocking Container 一样自动工作。

然而,AutoFixture 是一个非常可扩展的库,所以如果你真的必须这样做,应该可以编写一个可以写入私有属性的扩展,但它不会是最简单的曾经编写过 AutoFixture 扩展。

【讨论】:

  • 感谢鼓舞人心的 cmets!我确实将 DI 和 AutoFixture 与 Moq 一起用作自动模拟容器。我正在为我的类使用属性注入,因为构造函数注入对我来说似乎是样板。我还使用私有属性来防止来自外部的修改,以防止任何可能的错误。只要(DI +测试)工具能够设置私有字段,就可以正常工作:)我想,我应该学会使用样板文件并更喜欢构造函数注入来正确地做事,因为无论如何都应该管理依赖关系.非常感谢 AutoFixture!
  • 我不确定我是否理解为什么构造函数比属性更多样板......无论如何,如果你有依赖关系,你应该prefer Constructor Injection。更多详情,请阅读my book :)
  • 注解一个字段比在构造函数中接收它然后将它分配给一个字段要容易得多。诚然,使用字段注入添加太多依赖项太容易了,但 IDE 会警告您。另外,老实说,我是在现场注射长大的,这似乎是我的一个坏习惯。经验教训,更喜欢构造函数注入。谢谢你教育我!哦,我绝对应该阅读一些 .NET 书籍,因为这是我的第一个 .NET 项目!
猜你喜欢
  • 1970-01-01
  • 2012-02-10
  • 2010-09-29
  • 1970-01-01
  • 1970-01-01
  • 2014-11-03
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多