visual testmethod studio net gui nunit

testmethod - nunit.net core



¿Por qué testFixture en lugar de TestClass? (3)

Ahora que lo preguntas, simplemente lo busqué.
Un dispositivo de prueba es el estado de referencia fijo que debe establecerse antes de que se ejecuten las pruebas, de modo que los resultados sean predecibles y repetibles. En marcos de prueba de unidad, usamos los atributos / métodos SetUp y TearDown para crear / destruir el dispositivo de prueba (por ejemplo, inicializar variables de instancia con los objetos correctos).

Hay tres formas de organizar pruebas de unidad: Prueba por Aparato, Clase o Característica. Pero el atributo NUnit para TestClass se llama TestFixture. ¿Hay alguna razón histórica para eso?


La principal razón histórica es que NUnit comenzó su vida como un puerto directo de JUnit y Junit lo llamó dispositivo de prueba.

NUnit 1.0 era anterior a mi tiempo, pero me dijeron que comenzó cambiando el nombre de todos los archivos .java en JUnit a archivos .cs y tratando de compilar. Se solucionó desde allí y se agregó una interfaz de usuario. Cuando me uní a NUnit 2.0 todavía había un método en NUnit 1.0 llamado IsVisualAgeForJava ya que JUnit tenía un comportamiento especial para eso en ese momento.

En NUnit 2.0, nuestro objetivo era hacer que NUnit fuera más .NET. Así que agregamos los atributos y un montón de otras cosas. Todos proveníamos de fondos de Java y habíamos trabajado con JUnit durante años. Parecía bastante natural utilizar [TestFixture] .


Respeto la respuesta de Mike Two, pero afirmaría que el equipo de NUnit se equivocó, y el uso de [TestFixture] es una verruga semántica en la cara de NUnit. Una clase de prueba no es un accesorio . Por lo que he descubierto en relación con JUnit, no he encontrado ninguna referencia a una clase de prueba como un dispositivo de prueba, ni he encontrado mucha discusión sobre "dispositivos de prueba" en relación con las clases de prueba. Más bien, toda la discusión de JUnit / xUnit sobre los dispositivos se refiere a la configuración y el desmontaje, que, por supuesto, son los métodos comunes que se utilizan para configurar los dispositivos de prueba reales.

Tenga en cuenta que en NUnit 2.5, puede eliminar la anotación [TestFixture].

Actualización: (Julio 2012)

Acabo de leer Cucumber Book y en la página 99, el autor Matt Wynne explica el origen del uso de "fixture". Yo cito:

Existe una larga tradición (proveniente del mundo del hardware, donde los dispositivos de prueba se originaron) de llamar al enlace entre el sistema de prueba y el sistema bajo prueba un dispositivo. Este es el rol de "código de cola" al que nos hemos referido en este libro como código de automatización. El marco de pruebas FIT utiliza este significado del término. Algunas herramientas de prueba de unidad (como NUnit) han confundido aún más el problema al referirse a la clase de caso de prueba como un elemento fijo. ¡Tanto para un lenguaje ubicuo! (Wynne & Hellesoy, 2012)