Autofixture: rendre AutoFixture statique

Créé le 28 août 2013 · 4Commentaires · Source: AutoFixture/AutoFixture

[Ceci est une demande d'amélioration]

Ce serait cool si nous pouvions écrire

Fixture.Créer();

au lieu d'instancier un Fixture
var fixture = new Fixture();
luminaire.Créer();

Dans votre présentation au NDC d'autofixture, vous avez dit que vous détestiez déclarer une variable dans le constructeur d'une classe de test afin de l'utiliser dans chaque méthode de test. Vous avez dit qu'il est plus clair de tout voir dans une seule méthode. J'ai suivi ton idée car je pense que c'est une bonne idée, mais le problème c'est que je suis actuellement en train d'instancier un nouveau Fixture dans chaque méthode et je ne suis pas vraiment fan, je préférerais appeler Fixture.Create();

Qu'en penses-tu ?

Ouais je sais, je pourrais utiliser la méthode déclarative, mais je ne suis pas un grand fan, car je vais devoir créer une nouvelle classe qui implémente ICustomize. Par conséquent, je ne verrai pas tout dans une seule méthode de test. Je vais devoir naviguer jusqu'à la classe pour voir comment les données sont configurées. De plus, la plupart de mes méthodes ont différentes manières de configurer les données, je ne veux donc pas créer une classe qui implémente ICustomize pour chacune de mes méthodes de test.

Source

Accc99

🚀1 👍1

Tous les 4 commentaires

En plus d'enregistrer 6 frappes, comment

``` c#
var foo = Fixture.Créer();

provide any advantage that

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

n'est-ce pas ?

Le problème des frappes supplémentaires peut être résolu en créant un extrait de code Visual Studio.

ploeh le 28 août 2013

👎1

Merci pour votre réponse Mark, En effet, l'extrait de code me permettra de taper plus rapidement, mais pour plus de lisibilité, je préfère lire ;

Fixture.Créer();
Montage.Construire();

que

nouveau Fixture().Créer();
nouveau Fixture().Build();

C'est une petite amélioration, mais cela ferait battre mon cœur encore plus lors de l'utilisation de la fixation automatique.

Accc99 le 28 août 2013

Assez juste. Cependant, la lisibilité est une chose subjective.

D'après mon expérience, dans la plupart des bases de code, les utilisateurs doivent personnaliser une instance de Fixture d'une manière ou d'une autre, afin de s'adapter à toutes les petites bizarreries de leur base de code ou des bibliothèques utilitaires qu'ils utilisent. Par exemple, vous ne pouvez pas utiliser une instance de Fixture simple pour tester les contrôleurs ASP.NET MVC, car (IIRC) certaines parties de ces classes de base ont des références circulaires.

Ainsi, en supposant qu'une méthode hypothétique Fixture.Create<T>() fonctionnerait à partir d'une instance de Fixture simple, je la considère d'une utilité limitée.

Ce n'est pas une direction dans laquelle je souhaite prendre AutoFixture, je vais donc clore cette suggestion.

Cependant, rien ne vous empêche de créer vous-même un tel wrapper ; ce serait assez trivial à mettre en œuvre.

ploeh le 28 août 2013

👎1

J'aime aussi l'idée de conserver le nouveau Fixture () mais également d'avoir un raccourci statique supplémentaire (vers une instance statique privée) dans la bibliothèque elle-même. Il est trivial d'écrire un wrapper ou une méthode d'extension, mais peu gênant à gérer (par exemple l'espace de noms) et à transférer de projets en projets.
Merci,