Pruebas que dependen de la funcionalidad de uso común con NUnit

Question

Tengo un código de inicialización para usar mi API. La inicialización puede fallar y me gustaría probarla en una prueba NUnit.

Después de la inicialización, se puede usar la API. También estoy probando la API, pero todos mis métodos de prueba usarán el mismo código de inicialización común.

Lo que idealmente me gustaría es si este comportamiento:

1. La prueba se ejecuta la inicialización.
2. Las otras pruebas se ejecutan si [1] tuvo éxito.

En todos los casos donde [1] fallará, también lo harán todas las demás pruebas. Pero la información valiosa es que [1] falla. Ahí es donde probablemente encuentre el problema. Sería bueno si las otras pruebas se pueden marcar con? o algo así, lo que indica que no se ejecutaron porque la funcionalidad de la que dependen no pasó las pruebas.

Sé que las pruebas no deben ser frágiles. Pero no puedo evitar el hecho de que el código de inicialización es necesario para la correcta ejecución de otras funciones.

Este es un problema más general en el que algunas funciones dependen de otras funciones. Donde la "otra funcionalidad" se utiliza con demasiada frecuencia para proporcionar un valor real al fallar todas las pruebas que dependen de él. Sería mejor si la "otra funcionalidad" se probara por separado.

Answer 1

Estuve en contacto con los desarrolladores de NUnit. No es posible en este momento sin escribir un plugin bastante complejo. La característica aparecerá en algún lugar de la base de código 3.x pero no aparecerá en 2.5. Consideraré escribirlo, pero no por el momento.

Answer 2

bien aquí es cómo iba a ir sobre esto ...

Ponga la inicialización común en un método de instalación desde su necesaria para todas las pruebas. Si la inicialización genera un error, verías

• todas las pruebas en una suite (que no he sido entrenado con el tiempo a reconocer como un indicio de que tal instalación/desmontaje ha lanzado una excepción).
• stacktrace para las pruebas fallidas que contienen el método de instalación.

Si esto es demasiado implícito para usted, puede (aunque yo no lo recomendaría) agregar una prueba vacía con un buen nombre a la misma suite. Si esa prueba se muestra en verde, puede estar seguro de que el programa de instalación/código de inicio común ha tenido éxito.

[Test] 
public void VerifySetup() {} 

Actualización: Parece que tiene un requisito bastante nicho. No conozco ningún mecanismo en NUnit para especificar dicha ejecución condicional de las pruebas, p. Ejecute Test2 hasta 10 solo si pasa Test1.

Answer 3

Prueba esto:

1. Definir la "prueba de inicialización" como un TestCase

2. hacer todas sus otras pruebas de una subclase de esta TestCase

3. crear un conjunto que se ejecuta sus pruebas en algún orden específico para que su "prueba de inicialización" sea la primera.

Answer 4

Creo que este corte bastante claro.El problema es que te está costando separar tus responsabilidades de API. Tienes dos. Inicialización de API y ejecución de API. Escribir tus pruebas para tener este tipo de dependencia puede matarte.

Así que recomendaría que la API cree un objeto de inicialización y luego varios objetos de comando para ejecutar la API. Los objetos de comando estarán en algún tipo de tienda o podría crear sobre la marcha.

La API utilizará un objeto de inicialización simulado y utilizará objetos de comando simulados.

El objeto de inicialización realmente no tiene ninguna dependencia, excepto lo que necesite inicializar.

Los objetos Command necesitarán un objeto de inicialización falso.

[EDIT]

Hay dos vías para conseguir las otras pruebas para fallar si la prueba falla la inicialización

1. Agregar una variable privada para el caso de prueba. private isInitialized = false;. Luego, todas sus otras pruebas verifican el estado de esta variable si no es verdadera y luego falla.

2. Amplíe su caso de prueba con la clase API. Agregar función privada que interrogue el estado de inicialización.

El limpiador de los dos es 2. La implementación más rápida es 1.

mi humilde opinión Esto puede ser un olor código cuando se tiene que acoplar sus pruebas de tal manera. Si como dijiste es una prueba de integración. ¿Por qué tienes una prueba separada para la inicialización? La integración es más parecida a ejecutar alguna acción contra su API. Por lo tanto, cada prueba de integración DEBE inicializar la API.

Es posible que desee volver a pensar su escenario de falla en cascada. Puede ser demasiado ruido al completar las pruebas.

[EDIT1a]

La única manera que puedo ver para satisfacer sus requisitos es extend NUnit. Mire específicamente en Test Case Builders y Decoradores de prueba.

El enlace está fechado en marzo de 2008, así que espero que no esté desactualizado.