Autofixture: hacer AutoFixture estático

Creado en 28 ago. 2013 · 4Comentarios · Fuente: AutoFixture/AutoFixture

[Esta es una solicitud de mejora]

Sería genial si pudiéramos escribir

Accesorio Crear();

en lugar de instanciar un accesorio
var fixture = new Fixture ();
accesorio Crear();

En su presentación en NDC de autofixture, dijo que odiaba declarar una variable en el constructor de una clase de prueba para usarla en cada método de prueba. Dijiste que es más claro ver todo dentro de un método. Seguí tu idea porque creo que es una buena idea, pero el problema es que actualmente estoy creando una instancia de un nuevo Fixture en cada método y no soy muy fan, preferiría llamar al Fixture.();

Qué piensas ?

Sí, lo sé, podría usar la forma declarativa, pero no soy un gran fan, porque tendré que crear una nueva clase que implemente ICustomize. Por lo tanto, no veré todo dentro de un método de prueba. Tendré que navegar hasta la clase para ver cómo se configuran los datos. Y más, la mayoría de mis métodos tienen diferentes formas de configurar los datos, así que no quiero crear una clase que implemente ICustomize para cada uno de mi método de prueba.

Fuente

Accc99

🚀1 👍1

Todos 4 comentarios

Aparte de guardar 6 pulsaciones de teclas, ¿cómo

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

provide any advantage that

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

no?

El problema de las pulsaciones de teclas adicionales se puede solucionar creando un fragmento de código de Visual Studio.

ploeh en 28 ago. 2013

👎1

Gracias por tu respuesta Mark, De hecho, el fragmento de código me permitirá escribir más rápido, pero para mejorar la legibilidad, prefiero leer;

Accesorio Crear();
Accesorio Construir();

que

nuevo Aparato (). Crear();
new Fixture (). Construir();

Esta es una pequeña mejora, pero haría que mi corazón latiera aún más cuando utilizo la autofijación.

Accc99 en 28 ago. 2013

Lo suficientemente justo. Sin embargo, la legibilidad es algo subjetivo.

En mi experiencia, en la mayoría de las bases de código, la gente tiene que personalizar una instancia de Fixture de una forma u otra, para acomodar todas las pequeñas peculiaridades de su base de código, o las bibliotecas de utilidades que utilizan. Como ejemplo, no puede usar una instancia simple de Fixture vanilla para probar controladores ASP.NET MVC, porque (IIRC) hay ciertas partes de esas clases base que tienen referencias circulares.

Por lo tanto, suponiendo que un método hipotético Fixture.Create<T>() funcionaría en una instancia simple de un accesorio básico, lo considero de utilidad limitada.

Esta no es una dirección en la que deseo tomar AutoFixture, así que voy a cerrar esta sugerencia.

Sin embargo, nada le impide crear usted mismo dicha envoltura; sería bastante trivial de implementar.

ploeh en 28 ago. 2013

👎1

También me gusta la idea de mantener el nuevo Fixture () pero también tener un acceso directo estático adicional (a una instancia estática privada) en la propia biblioteca. Es trivial escribir un contenedor o un método de extensión, pero un poco problemático de administrar (por ejemplo, el espacio de nombres) y transferirlo de proyectos a proyectos.
Gracias,