Autofixture: AutoFixture statisch machen

Erstellt am 28. Aug. 2013  ·  4Kommentare  ·  Quelle: AutoFixture/AutoFixture

[Dies ist eine Verbesserungsanfrage]

Es wäre cool, wenn wir schreiben könnten

Fixture.Create();

anstatt ein Fixture zu instanziieren
var Fixture = new Fixture();
Fixture.Create();

In Ihrer Präsentation von Autofixture bei NDC sagten Sie, dass Sie es hassen, Variablen im Konstruktor einer Testklasse zu deklarieren, um sie in jeder Testmethode zu verwenden. Sie sagten, es sei klarer, alles in einer Methode zu sehen. Ich bin deiner Idee gefolgt, weil ich es für eine gute Idee halte, aber das Problem ist, dass ich derzeit in jeder Methode ein neues Fixture instanziiere und ich nicht wirklich ein Fan bin, ich würde es vorziehen, Fixture.Create aufzurufen();

Was denkst du ?

Ja, ich weiß, ich könnte den deklarativen Weg verwenden, aber ich bin kein großer Fan, weil ich eine neue Klasse erstellen muss, die ICustomize implementiert. Daher werde ich nicht alles in einer Testmethode sehen. Ich muss zur Klasse navigieren, um zu sehen, wie die Daten eingerichtet sind. Darüber hinaus haben die meisten meiner Methoden unterschiedliche Methoden zum Einrichten der Daten, daher möchte ich nicht eine Klasse erstellen, die ICustomize für jede meiner Testmethoden implementiert.

Alle 4 Kommentare

Abgesehen von dem Speichern von 6 Tastenanschlägen, wie funktioniert?

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

provide any advantage that

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

nicht?

Das Problem mit zusätzlichen Tastenanschlägen kann durch Erstellen eines Visual Studio- Codeausschnitts behoben werden .

Vielen Dank für Ihre Antwort Mark, Code-Snippet ermöglicht es mir zwar, schneller zu tippen, aber aus Gründen der Lesbarkeit lese ich lieber;

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

als

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

Dies ist eine kleine Verbesserung, aber es würde mein Herz noch mehr schlagen lassen, wenn ich Autofixture verwende.

Meinetwegen. Lesbarkeit ist jedoch eine subjektive Sache.

Meiner Erfahrung nach müssen die Leute in den meisten Codebasen eine Fixture-Instanz auf die eine oder andere Weise anpassen, um all die kleinen Eigenheiten ihrer Codebasis oder der von ihnen verwendeten Dienstprogrammbibliotheken zu berücksichtigen. Beispielsweise können Sie keine einfache Vanilla Fixture-Instanz zum Testen von ASP.NET MVC-Controllern verwenden, da (IIRC) bestimmte Teile dieser Basisklassen über Zirkelverweise verfügen.

Angenommen, eine hypothetische Fixture.Create<T>() Methode würde mit einer einfachen Fixture-Instanz funktionieren, halte ich sie für begrenzt nützlich.

Dies ist keine Richtung, in die ich AutoFixture einschlagen möchte, daher werde ich diesen Vorschlag schließen.

Es hindert Sie jedoch nichts daran, einen solchen Wrapper selbst zu erstellen; es wäre ziemlich trivial zu implementieren.

Ich mag auch die Idee, neue Fixture() beizubehalten, aber auch eine zusätzliche statische Verknüpfung (zur privaten statischen Instanz) in der Bibliothek selbst zu haben. Es ist trivial, einen Wrapper oder eine Erweiterungsmethode zu schreiben, aber etwas mühsam zu verwalten (zB Namespace) und von Projekten zu Projekten zu übertragen.
Danke,

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen