Autofixture: make AutoFixture static

Created on 28 Aug 2013 · 4Comments · Source: AutoFixture/AutoFixture

[This is an enhancement request]

It would be cool if we could write

Fixture.Create();

instead of instantiating a Fixture
var fixture = new Fixture();
fixture.Create();

In your presentation at NDC of autofixture, you said that you hate declaring variable in constructor of a test class in order to use it in every test method. You said it's clearer to see everything inside one method. I followed your idea because I think it's a good idea, but the problem is that I'm currently instantiating a new Fixture in each method and I'm not really fan, I would prefer to call Fixture.Create();

What do you think ?

Yeah I know, I could use the declarative way, but I'm not a big fan, because I'll have to create a new class which implement ICustomize. Therefore, I will not see everything inside one test method. I'll have to navigate to the class to see how the data is setup'ed. And more, most of my methods have different way to setup the data, so I don't want to create one class which implements ICustomize for each one my test method.

Source

Accc99

🚀1 👍1

All 4 comments

Apart from saving 6 keystrokes, how does

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

provide any advantage that

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

doesn't?

The issue about extra keystrokes can be addressed by creating a Visual Studio code snippet.

ploeh on 28 Aug 2013

👎1

Thanks for your answer Mark, Indeed, code snippet will allow me to type faster, but for readability, I prefer to read;

Fixture.Create();
Fixture.Build();

than

new Fixture().Create();
new Fixture().Build();

This is a little enhancement, but it would make my heart beating even more when using autofixture.

Accc99 on 28 Aug 2013

Fair enough. However, readability is a subjective thing.

In my experience, in most code bases, people have to customize a Fixture instance one way or another, in order to accommodate all the small quirks of their code base, or the utility libraries they use. As an example, you can't use a plain vanilla Fixture instance to test ASP.NET MVC Controllers, because (IIRC) there are certain parts of those base classes that have circular references.

Thus, assuming that a hypothetical Fixture.Create<T>() method would work off a plain vanilla Fixture instance, I consider it of limited usefulness.

This is not a direction in which I wish to take AutoFixture, so I'm going to close this suggestion.

However, nothing prevents you from creating such a wrapper yourself; it would be quite trivial to implement.

ploeh on 28 Aug 2013

👎1

I also like the idea to keep new Fixture() but also have additional static shortcut (to private static instance) in the library itself. It is trivial to write a wrapper or an extension method, but little bit troublesome to mange (e.g. namespace) and carry over from projects to projects.
Thanks,