2009-09-24 13 views

Respuesta

2

suena como una idea peligrosa a menos que sea una prueba de integración, con decir datos para eliminar decir. ¿Por qué no hacerlo en la prueba en sí?

Obviamente se podría establecer una bandera privada en la clase.

Esto es lo mismo Charlie Poolehas suggested si es necesario

+1

Eso es molesto, lo habría hecho esperaba algún tipo de API NUnit.CurrentTestContext. Solo necesito saber si la prueba fue exitosa, ya que hay información adicional que puedo proporcionar en este dispositivo si falla que ayudaría en la depuración. –

2

Sólo si lo hace de forma manual. De hecho, ni siquiera sabrá qué pruebas pretenden ejecutar. En NUnit IDE uno puede habilitar algunas pruebas y desactivar algunas otras. Si desea saber si alguna prueba específica se ha quedado usted podría incluir un código como este en su clase de prueba:

enum TestStateEnum { DISABLED, FAILED, SUCCEDED }; 
TestStateEnum test1State = TestStateEnum.DISABLED; 

[Test] 
void Test1() 
{ 
test1State = TestStateEnum.FAILED; // On the beginning of your test 
... 
test1State = TestStateEnum.SUCCEDED; // On the End of your Test 
} 

entonces usted puede comprobar la variable test1State. Si la prueba arroja una excepción, no establecerá el SUCCEDED. también se puede poner esto en un intento de captura por último bloque en sus pruebas con una lógica ligeramente diferente:

[Test] 
void Test1() 
{ 
test1State = TestStateEnum.SUCCEDED; // On the beginning of your test 
try 
{ 
    ... // Your Test 
} 
catch(Exception) 
{ 
    test1State = TestStateEnum.FAILED; 
    throw; // Rethrows the Exception 
} 
} 
+0

No es un intento de decir qué prueba se ejecutó, solo un error diferente que me gustaría arrojar para poder obtener una stacktrace más precisa –

-1

mi humilde opinión derribar la lógica debe ser independiente de los resultados de las pruebas.

Lo ideal sería evitar el uso de la configuración y el desmontaje por completo, a al xunit.net. Vea here para más información.

+0

Como regla, absolutamente eso es lo que debes hacer. Sin embargo, me gusta mantener mis pruebas limpias y cohesivas con un sabor BDD. A veces eso significa configurar datos y afirmaciones a través de lambdas y ejecutarlas en TearDown. El problema es si, por alguna razón, la configuración o el cuerpo de prueba fallaron, la pila de datos es confusa. –

25

Esto ya se ha resuelto en Ran's answer a una pregunta similar. Citando Ran:

Desde la versión 2.5.7, NUnit permite que Teardown detecte si falló la última prueba. Una nueva clase TestContext permite que las pruebas accedan a información sobre ellas mismas, incluidas las TestStauts.

Para más detalles, por favor refiérase a http://nunit.org/?p=releaseNotes&r=2.5.7

[TearDown] 
public void TearDown() 
{ 
    if (TestContext.CurrentContext.Result.Status == TestStatus.Failed) 
    { 
     PerformCleanUpFromTest(); 
    } 
} 
+0

Gracias por el enlace. Tenga en cuenta que esta pregunta se publicó más de un año y medio antes de la respuesta de David. –

+3

En Nunit 3.x es 'if (TestContext.CurrentContext.Result.Outcome == ResultState.Failure)' – Lukas

4

Si desea utilizar TearDown para detectar el estado de la última prueba con NUnit 3.5 que debe ser:

[TearDown] 
public void TearDown() 
{ 
    if (TestContext.CurrentContext.Result.Outcome.Status.Equals(TestStatus.Failed)) 
    { 
     //your code 
    } 
} 
Cuestiones relacionadas