Nunit: El resultado vacío del generador `TestCaseSource` debería fallar la prueba

Creado en 3 jun. 2020  ·  3Comentarios  ·  Fuente: nunit/nunit

Al usar [TestCaseSource(nameof(GeneratorMethod))] , tendría sentido fallar la prueba (o marcarla como omitida) si el generador no produce entradas. Al menos no muestres la prueba como aprobada :/

Comentario más útil

Algunos puntos a considerar...

  1. Puede haber múltiples fuentes, por lo que debemos tener claro si la discusión se aplica a __cada__ fuente o al resultado agregado de todas las fuentes.

  2. Las fuentes generan pruebas, no solo datos. Si no se generan pruebas, entonces no hay nada que fallar u omitir. En el pasado distante (V2) generamos una prueba fallida falsa, que terminó siendo desordenada en el código y confusa para los usuarios.

  3. Un método de prueba sin casos es un poco como un método sin código. También como un accesorio sin pruebas. Consideramos los que pasan.

  4. Si llama a su prueba una teoría, obtendrá un fracaso si no hay un caso de aprobación.

Votaría por dejar el comportamiento actual pero darle al usuario alguna forma de solicitar un mensaje de advertencia si no se generan casos.

Todos 3 comentarios

Si la memoria no me falla, funciona como lo hace debido a un informe de error hace algunos años, que nos convenció de que debería pasar en este caso.

😢

Acabo de escribir una prueba con (actualmente) un elemento en la fuente y, al ser una prueba nueva en un ciclo TDD, esperaba que fallara, solo para descubrir que pasó... así que tuve que rastrear mi generador defectuoso.

Tal vez el fracaso sea un poco draconiano (mi preferencia, pero puede ser molesto para el reportero del número anterior). ¿Qué hay de marcar la prueba como omitida?

Algunos puntos a considerar...

  1. Puede haber múltiples fuentes, por lo que debemos tener claro si la discusión se aplica a __cada__ fuente o al resultado agregado de todas las fuentes.

  2. Las fuentes generan pruebas, no solo datos. Si no se generan pruebas, entonces no hay nada que fallar u omitir. En el pasado distante (V2) generamos una prueba fallida falsa, que terminó siendo desordenada en el código y confusa para los usuarios.

  3. Un método de prueba sin casos es un poco como un método sin código. También como un accesorio sin pruebas. Consideramos los que pasan.

  4. Si llama a su prueba una teoría, obtendrá un fracaso si no hay un caso de aprobación.

Votaría por dejar el comportamiento actual pero darle al usuario alguna forma de solicitar un mensaje de advertencia si no se generan casos.

¿Fue útil esta página
0 / 5 - 0 calificaciones