Digamos que crea una aplicación que intente transcribir las cosas del alfabeto A al alfabeto B, lo más cerca posible.¿Deberían todas las pruebas unitarias ser exitosas?
Como el lenguaje B es muy complejo, esto no siempre es exitoso. Pero obtienes una transliteración aproximada.
¿Cómo construirías pruebas unitarias en este caso, considerando que esperas que el 20-30% falle?
Siempre debe ser el objetivo que la prueba de su unidad sea exitosa. En la forma en que lo usa, no puede diferenciar entre los errores graves de su software y los errores en las traducciones que parece esperar.
sugeriría a separar ambos:
Una prueba de unidad que se espera que falle no es una prueba unitaria. Debe cambiar la definición de éxito mediante el uso de una función de evaluación que actúa como un filtro y decide si está "lo suficientemente cerca" y determina si pasa o no. A medida que su traductor mejore, puede subir la barra en el filtro.
La prueba de la unidad debe ser determinista. La prueba fallida debe indicar una falla del software, no es algo que "funciona como se esperaba". Para su caso, prepare los datos de manera que pueda estar seguro de los resultados y los pruebe, independientemente de si la conversión es correcta o no (la prueba de falla siempre es una opción, dado que espera una falla; es importante que siempre tenga el control de cuando su prueba pasa/falla).
Una técnica que he aprendido en esta situación es probar solo las partes del código que son funcionales (o deterministas). Por supuesto, la parte difícil es separar las partes deterministas de las no deterministas. La forma abreviada de decir esto es 'reducir [o refactorizar] a funcional', lo que significa separar las partes del código que son deterministas, y luego probar esas partes.
Para un fragmento de contexto basado en escenarios, lea esta publicación blog sobre la aplicación de esta técnica cuando realice pruebas en torno al código heredado (y utilizando la biblioteca de pruebas de unidad de código abierto denominada ApprovalTests).
Otra técnica más que puede interesar aquí es la prueba basada en la teoría. Para obtener más información al respecto, consulte esta publicación blog.
La única razón por la cual una prueba de la unidad podría fallar es si se trata de la temporización (principalmente en el caso de la electrónica que se está probando). Sin embargo, incluso si esos casos, el objetivo debe ser eliminar el problema de tiempo de la prueba unitaria, p. extendiendo/cambiando el tiempo de espera u otro problema de tiempo si es posible. Cuando no es posible, debe estar bien documentado.
Otra forma de eliminar los problemas de temporización y hacer que las pruebas sean determinantes es escribir apéndices para todas las interfaces externas, con algún método de inyección, es decir, poder establecer los valores que devolverán los métodos de interfaz externos. Al configurar una prueba unitaria de esta manera, puede probar literalmente todo y también cada condición de error.
(historia: Trabajé en una empresa donde varias pruebas unitarias fallarían ocasionalmente. Solo unas pocas personas pudieron analizar si se trataba de errores serios o un problema de tiempo.Se ahorrará mucho tiempo para realizar buenas pruebas unitarias en El primer lugar).
+1 para separar * unidades * pruebas que validan la corrección del programa a partir de * pruebas de aceptación * que validan que el programa cumple los requisitos especificados. –