¿Utiliza TestInitialize o el constructor de la clase de prueba para preparar cada prueba? ¿y por qué?

Question

Esta pregunta se refiere a las pruebas unitarias en Visual Studio usando MSTest (esto es importante, debido a execution order de MSTest). Tanto el método marcado [TestInitialize] como el constructor de la clase de prueba se ejecutarán antes de cada método de prueba.

Entonces, la pregunta es, ¿qué tienden a hacer en cada una de estas áreas? ¿Evita realizar ciertas actividades en cualquiera de los dos? ¿Cuál es tu razón: estilo, técnica, superstición?

Answer 1

El constructor es solo una estructura proporcionada por el idioma. Cada marco de prueba parece tener su propio ciclo de vida controlado "inicializar". Probablemente solo tendrá problemas al usar el constructor para mutar sus locals.

MSTest: Obtiene una instancia completamente nueva de la clase de prueba para cada TestMethod. Este podría ser el único caso en el que está permitido cambiar las ubicaciones locales en el constructor, el inicializador o el método de prueba y no afectar los otros métodos de prueba.

public class TestsForWhatever 
{ 
    public TestsForWhatever() 
    { 
     // You get one of these per test method, yay! 
    } 

    [TestInitialize] 
    public void Initialize() 
    { 
     // and one of these too! 
    } 

    [TestMethod] 
    public void AssertItDoesSomething() { } 

    [TestMethod] 
    public void AssertItDoesSomethingElse() { } 
} 

MSpec: Sólo tienes una Establish y Because para todas sus afirmaciones (It). Por lo tanto, no mutes a tus lugareños en tus afirmaciones. Y no dependas de las mutaciones de los locales en contextos base (si los usas).

[Subject(typeof(Whatever))] 
public class When_doing_whatever 
{ 
    Establish context =() => 
    { 
     // one of these for all your Its 
    }; 

    Because of =() => _subject.DoWhatever(); 

    It should_do_something; 
    It should_do_something_else; 
} 

Answer 2

El objeto que prueba no necesita ser instancied en el método [TestInitialize]. Puede probar el constructor de su objeto en un método de prueba [Prueba].

El objeto en [TestInitialize] puede ser configurar su almacenamiento de persistencia o preparar el valor que el objeto probado utilizará en las pruebas.

Answer 3

Prefiero usar el método [TestInitialize] para realizar una instanciación del objeto que se está probando y sus parámetros. Solo realizo trabajo en el constructor si es necesario crear una instancia de una clase base de prueba (que generalmente es donde creo o actualizo repositorios, etc.). Esto me ayuda a mantener el código de prueba y el código de prueba separados de forma lógica y física.

Answer 4

Esta pregunta también se le pide (más tarde) en What’s the difference between using the constructor in VS Testing framework vs. TestInitialize() attribute?

Fwiw Asumo por "constructor de la clase" que significa la instance constructor (no el static constructor).

creo que la misma pregunta que usted está pidiendo se puede pedir por igual sobre la frente constructor estático ClassInitialize ...

Answer 5

La principal ventaja de utilizar ya sea TestInitialize() o ClassInitialize() en lugar de la instancia de clase de prueba o constructores estáticos es su naturaleza explícita. Comunica claramente que está realizando una configuración antes de sus pruebas. Hacer esto consistentemente debería mejorar el mantenimiento a largo plazo.

Answer 6

Aquí hay algunas ventajas que he encontrado con TestInitialize.

• Algunas variables del entorno (por ejemplo, TestContext) no son accesibles hasta que se crea una instancia de la clase de prueba.
• Puede requerir implementación con la clase derivada marcando un método base TestInitialize abstract.
• Puede anular fácilmente un método TestInitialize base y determinar si se llama a la impl base antes de la impl derivada, después o en absoluto. Por el contrario, si deriva una clase de prueba de una clase de prueba base, en el caso de un constructor sin parámetros, se llamará al ctor base tanto si lo intentó como si no.
• Su definición explícita aclara las intenciones y complementa el método TestCleanup. Podría argumentar que puede crear un destructor para cada constructor, pero no se garantiza que MS Test maneje los destructores como era de esperar.

Answer 7

Depende de la situación. Si tiene una clase de prueba, y por algún motivo extraño si necesita crear una instancia de la misma en otra clase de prueba, necesitará usar el constructor.

De lo contrario, la prueba de inicialización encaja más en el concepto. En primer lugar, las mismas razones escritas anteriormente, el segundo MS puede introducir más características en ese atributo y usted las beneficiará, con el constructor se quedará atrapado en él.

Answer 8

Digo usar el constructor a menos que necesite TestContext.

1. Si puede mantener las cosas simples, ¿por qué no? Un constructor es más simple que un atributo mágico.
2. Puede usar readonly, que es una gran cosa en la inicialización de pruebas en la que desea preparar cosas para las pruebas que se supone que no deben cambiar (idealmente, las cosas que prepare también serían inmutables).