make AutoFixture static

[Accc99]

[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.

[ploeh]

Apart from saving 6 keystrokes, how does

var foo = Fixture.Create<Foo>();

provide any advantage that

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

doesn't?

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

[Accc99]

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.

[ploeh]

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.

[RyanLiu99]

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,