Assert.Inconclusive and IgnoreAttribute

Question

¿Cuál es la forma correcta de usar Assert.Inconclusive y IgnoreAttribute en el marco de prueba de MS Unit?

Estamos utilizando Assert.Inconclusive principalmente para pruebas que son:

• No implementado todavía
• De alguna manera roto o incompleto = requiere atención futher
• Cuando el cuerpo de prueba se por cualquier razón comentada

Hacemos esto porque:

• prueba no concluyente puede tener mensaje
• Queremos ver estas pruebas en los resultados de pruebas de TFS

Nuestro problema es que Inconclusive pruebas se marcan como errores tanto en TFS y ReSharper. Si usamos el IgnoreAttribute, veremos estas pruebas en Resharper, pero MS Test Runner y TFS las ignorarán. Usar IgnoreAttribute en TFS y MS Test Runner es lo mismo que comentar una prueba completa que es inútil.

Answer 1

Me gusta pensar que estás describiendo el uso correcto de Inconclusive.

Aunque en mi experiencia, Inconclusive se trata más como una advertencia que como un error. De hecho, ellos son reportados en el TRX por separado de los errores:

<TestRun> 
    <ResultSummary outcome="Inconclusive"> 
     <Counters total="1" 
      executed="0" error="0" failed="0" 
      timeout="0" aborted="0" inconclusive="1" 
      passedButRunAborted="0" notRunnable="0" 
      notExecuted="0" disconnected="0" 
      warning="0" passed="0" completed="0" 
      inProgress="0" pending="0" /> 

normalmente me lance el ejecutable mstest de un > tarea < Exec en mi guión msbuild y luego mirar dentro de la TRX para determinar si fallara la acumulación .

Answer 2

He estado investigando esto y probándolo en casa. El resultado final es que creo que el atributo [Ignorar] para MSTest deja de lado por completo el método de prueba. Traté de ver la configuración en Visual Studio para ver si había una anulación, pero no pude encontrar nada.

Qué vergüenza, ya que no ver las pruebas ignoradas es malo, ya que puede terminar pensando que tiene un conjunto de 100 pruebas MSTest funcionando muy bien, pero resulta que hay 50 que faltan en los resultados que nunca sabía acerca de debido al atributo [Ignore]! Urgh.

Answer 3

Clásicamente, cuando se prueban, las pruebas unitarias deben ser muy específicas para que haya una correspondencia (cercana) uno a uno entre las características y las pruebas de estas características.

Para probar ciertas características, el sistema sometido a prueba (SUT) primero debe ponerse en un estado determinado. Una vez que se alcanza ese estado, la prueba puede realmente probar la función para la cual está diseñada. Ahora, cuál debería ser el estado de dicha prueba, si ya falla la parte de configuración. No puede hacer una declaración sobre el funcionamiento de la característica bajo prueba, ya que la prueba nunca alcanzó el estado requerido para ejercer la función.

En tales casos, es común asignar un resultado no concluyente, ya que simplemente no podemos saber si la característica funciona como debería y, por lo tanto, no podemos aprobar o suspender. El hecho de que la configuración en sí misma no funcione como se espera debería estar cubierta por una prueba separada.

Así que imagina, quiero probar que un 'foo' que ha sido 'bloqueado' devolverá un 0 cuando 'qux'ed. Esta prueba no debe probar si 'foo' puede ser 'bloqueado', por lo que cualquier falla en ser 'excluido' no dará resultado, mientras que una falla en la respuesta a 'qux' será correcta.

Answer 4

También veo un dilema en la implementación actual.

• Inconclusive afirmaciones se incluyen en el informe TRX, pero MSTest.exe volverán 1 (que significa error) después de la ejecución.
• TestMethods con el atributo Ignore no se informará como un error, pero son completamente ocultos del informe TRX.

mi entendimiento personal es el siguiente:

utilizar el atributo [Ignore] (temporalmente) desactivar/omitir el método:

[TestMethod] 
[Ignore] // <== disabled through "Ignore" attribute 
public void Test001() 
{ 
    //execute some stuff ... 
    Assert.IsTrue(...); 

    //execute some stuff ... 
    Assert.AreEqual(...); 
} 

hacer no el mal uso de la afirmación Inconclusive para este propósito:

[TestMethod] 
public void Test002() 
{ 
    Assert.Inconclusive(); // <== misuse of "Inconclusive" to skip this test 

    //execute some stuff ... 
} 

en su lugar, Inconclusive se debe usar condicionalmente: solo si no podemos decir si el componente que se probará funciona como se espera o no.
por ejemplo, en caso de que un externa recurso dependemos no está disponible en tiempo de ejecución de la prueba:

[TestMethod] 
public void Test003() 
{ 
    //check if the server is running, 
    //otherwise can can't test our local client component! 
    if (!WebServiceAvailable()) 
    { 
     Assert.Inconclusive(); // <== skip remaining code because the resource is not available 
    } 

    //execute some stuff ... 
    Assert.AreEqual(...); 

    //execute some stuff ... 
    Assert.AreEqual(...); 
} 

_ _

conclusión:
para desactivar/omitir una prueba de la lógica forma es utilizar el atributo [Ignore].
veo claramente que el comportamiento actual de mstest.exe no informa sobre ninguna prueba ignorada como error que se debe corregir.

sienten libres para arriba-votar los siguientes informes de errores:

• https://connect.microsoft.com/VisualStudio/feedback/details/779743/
• http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2088845

Answer 5

A partir de la documentación de MSDN:

1. IgnoreAttribute (desde VS 2005) significa "esta prueba no debe ejecutarse" ver https://msdn.microsoft.com/en-us/library/microsoft.visualstudio.testtools.unittesting.ignoreattribute(v=vs.80).aspx.

2. Assert.Concluyentes (desde VS 2005) significa "Indica que una afirmación no puede ser probada como verdadera o falsa. También se usa para indicar una afirmación de que aún no se ha implementado." ver https://msdn.microsoft.com/en-us/library/microsoft.visualstudio.testtools.unittesting.assert.inconclusive(v=vs.80).aspx

Creo que estos son realmente declaraciones claras cuando tienes que usar cual.