Autofixture: 使 AutoFixture 成为静态

创建于 2013-08-28 · 4评论 · 资料来源: AutoFixture/AutoFixture

[这是一个增强请求]

如果我们可以写的话会很酷

夹具.创建();

而不是实例化一个夹具
var fixture = new Fixture();
夹具.创建();

在您在 NDC 的 autofixture 演讲中，您说您讨厌在测试类的构造函数中声明变量以便在每个测试方法中使用它。您说在一个方法中查看所有内容更清晰。我遵循你的想法，因为我认为这是一个好主意，但问题是我目前正在每个方法中实例化一个新的 Fixture 而我并不是真正的粉丝，我更喜欢调用 Fixture.Create();

你怎么认为？

是的，我知道，我可以使用声明式方式，但我不是一个大粉丝，因为我必须创建一个实现 ICustomize 的新类。因此，我不会在一个测试方法中看到所有内容。我将不得不导航到该类以查看数据是如何设置的。而且，我的大多数方法都有不同的方法来设置数据，所以我不想创建一个类来为我的每个测试方法实现 ICustomize。

资料来源

Accc99

🚀1 👍1

所有4条评论

除了节省 6 次击键之外，还有什么

``` c#
var foo = Fixture.Create();

provide any advantage that

``` c#
var foo = new Fixture().Create<Foo>();

不是吗？

可以通过创建 Visual Studio代码片段来解决有关额外击键的问题。

ploeh 于 2013-08-28

👎1

感谢您的回答 Mark，确实，代码片段可以让我打字更快，但为了可读性，我更喜欢阅读；

夹具.创建();
夹具.构建();

比

新夹具（）。创建();
new Fixture().Build();

这是一个小小的改进，但它会让我在使用 autofixture 时心跳得更厉害。

Accc99 于 2013-08-28

很公平。然而，可读性是一个主观的东西。

根据我的经验，在大多数代码库中，人们必须以一种或另一种方式自定义 Fixture 实例，以适应其代码库或他们使用的实用程序库的所有小怪癖。例如，您不能使用普通的 Fixture 实例来测试 ASP.NET MVC 控制器，因为 (IIRC) 这些基类的某些部分具有循环引用。

因此，假设假设的Fixture.Create<T>()方法可以处理普通的 Fixture 实例，我认为它的用处有限。

这不是我希望采用 AutoFixture 的方向，因此我将关闭此建议。

但是，没有什么可以阻止您自己创建这样的包装器；实施起来非常简单。

ploeh 于 2013-08-28

👎1

我也喜欢保留 new Fixture() 的想法，但在库本身中还有额外的静态快捷方式（到私有静态实例）。编写包装器或扩展方法很简单，但管理（例如命名空间）和从项目到项目的继承有点麻烦。
谢谢，

RyanLiu99 于 2016-01-11

👍1

此页面是否有帮助？

0 / 5 - 0 等级

Autofixture: 使 AutoFixture 成为静态

所有4条评论

相关问题