afirmando configurar y precondiciones en la Unidad de Pruebas de

Question

Es tener más de un afirman por prueba un muy mal olor? Por lo general tratan de seguir el patrón de “organizar, actuar, hacer valer”, así como la aserción individual por directrices de ensayo. Creo que tener pruebas limpias, pequeñas y aisladas es pura maravilla. En general, logro hacer esto. Sin embargo, a veces me encuentro afirmando “condiciones previas” justo después de mi arreglos de esta manera:

'arrange: 
'pre-conditions:  
    Assert the arrange worked 
'act: 
'assert: 

Es mi prueba prueba demasiado? ¿Le importan las cosas que no deberían importarle? Me encantaría escuchar algunas opiniones sobre esto.

Answer 1

Como dije here, creo que tal vez nuestro mejor práctica debe ser, no Organizar-Ley-aserción, sino más bien Organizar- Supongamos -Ley-Assert. Antes de actuar, afirmamos que el resultado deseado de la acción aún no está en vigor. Esto no es exactamente lo mismo que lo que está pidiendo; en general, no creo que es importante verificar la instalación, debido a errores de configuración tienden a manifestarse bastante "fuerte" en cualquier caso; pero es una buena razón para tener una segunda afirmación en la prueba.

Answer 2

Creo que tener que usar Assert para validar la configuración es poco óptimo, ya que enturbia los resultados (puede ser difícil averiguar lo que está probando, si solo mira la salida).

Reconozco que hay momentos en que esto es necesario, o simplemente desea asegurarse de que todo se prueba de la manera que desea.

Mi práctica es utilizar Debug.Assert (en C#) para este fin, de modo que la validación de la configuración no se convierta en parte de la salida de prueba.

Puede lograr lo mismo en otros idiomas lanzando una excepción si la configuración no pone el sistema en un estado esperado.

diferentes corredores de la prueba pueden manejar esto de manera diferente, por lo que debe asegurarse de que este enfoque tiene el efecto deseado (pruebas fallan, pero no hay salida informe adicional, siempre y cuando los Debug.Assert pases o ninguna excepción lanzada).

Answer 3

No utilizaría un vainilla "Afirmar" para eso, sino más bien Assert.Inconclusive (MSTest) ¹. La prueba no ha fallado, por lo que no debe fallar la ejecución de la prueba.

1) Assume en JUnit y NUnit, creo.