.net unit-testing resharper mstest team-build

.net - Assert.Inconclusive and IgnoreAttribute



unit-testing resharper (5)

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

Estamos utilizando Assert.Inconclusive principalmente para pruebas que son:

  • Aun no implementado
  • De alguna manera roto o incompleto = requiere mayor atención
  • Cuando el cuerpo de prueba es por alguna razón comentado

Estamos haciendo esto porque:

  • Prueba no concluyente puede tener mensaje
  • Queremos ver tales pruebas en los resultados de las pruebas en TFS

Nuestro problema es que las pruebas no Inconclusive están marcadas como error tanto en TFS como en Resharper. Si usamos IgnoreAttribute en IgnoreAttribute lugar, veremos estas pruebas en Resharper pero MS Test runner y TFS las ignorarán en absoluto. El uso de IgnoreAttribute en TFS y MS Test runner es lo mismo que comentar la prueba completa, que es inútil.

A partir de los documentos de MSDN:

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

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

Creo que estas son declaraciones realmente claras cuando tienes que usar cuál.

Clásicamente, cuando se realizan las pruebas, las pruebas unitarias deben ser muy específicas para que exista una correspondencia (cercana a) entre las funciones y las pruebas de estas funciones.

Para probar ciertas características, el sistema bajo prueba (SUT) primero debe ponerse en cierto estado. Una vez que se alcanza ese estado, la prueba puede probar la función para la cual está diseñado. 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 función bajo prueba, ya que la prueba nunca alcanzó el estado requerido para ejercerla.

En tales casos, es común asignar un resultado no concluyente, ya que simplemente no podemos saber si la función funciona como debería, y por lo tanto no podemos pasar o fallar. El hecho de que la configuración en sí no funciona como se espera debe ser cubierto por una prueba separada.

Así que imagínate, quiero probar que un ''foo'' que ha sido ''bloqueado'' devolverá un 0 cuando ''qux''ed. Esta prueba no debería probar si ''foo'' puede ser ''bloqueado'', por lo que cualquier falla en ser ''bar''ed arrojará un resultado no concluyente, mientras que una falla en responder a'' qux ''será una falla apropiada.

He estado investigando esto y probándolo en casa. El resultado final es que creo que el atributo [Ignore] para MSTest omite completamente el método de prueba. Intenté ver las configuraciones en Visual Studio para ver si había una anulación, pero no pude encontrar nada.

Lástima, ya que no ver las pruebas ignoradas es malo, ya que puede terminar pensando que tiene un conjunto de 100 pruebas MSTest ejecutándose bien, pero resulta que hay 50 que faltan en los resultados que nunca conoció debido a el atributo [Ignore] ! Urgh.

Me gusta pensar cómo se describe Inconclusivo es el uso adecuado.

Aunque en mi experiencia, Inconclusive se trata más como una advertencia que como un error. De hecho, se informan 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 ejecuto el ejecutable mstest desde una tarea <Exec> en mi script msbuild y luego miro dentro del TRX para determinar si debería fallar la compilación.

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

  • Inconclusive aserciones no Inconclusive se incluyen en el informe TRX, pero mstest.exe devolverá 1 (es decir, error ) después de la ejecución.
  • TestMethods con el atributo Ignore no se informará como un error, pero están completamente ocultos del informe TRX.

Mi comprensión personal es la siguiente:

use el atributo [Ignore] para (temporalmente) deshabilitar / omitir el método:

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

No haga 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 debe usar condicionalmente : solo si no podemos saber si el componente que se va a probar funciona como se espera o no.
por ejemplo, en caso de que un recurso externo del que dependemos no esté disponible al momento de la 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 deshabilitar / omitir una prueba, la forma lógica es usar el atributo [Ignore] .
Veo claramente el comportamiento actual de mstest.exe no informa sobre ninguna prueba ignorada como un error que debería solucionarse.

no dude en votar los siguientes informes de errores: