Mi interpretación de esa charla es:
- componentes de prueba, no clases.
- probar componentes a través de sus puertos de interfaz.
No se menciona en la charla, pero creo que el contexto asumido para el consejo es algo como:
- está desarrollando un sistema para usuarios, no, por ejemplo, una biblioteca o marco de utilidad.
- El objetivo de las pruebas es entregar con éxito la mayor cantidad posible dentro de un presupuesto competitivo.
- Los componentes se escriben en un lenguaje único, maduro, probablemente de tipo estático, como C # / Java.
- un componente es del orden de 10000-50000 líneas; un proyecto Maven o VS, un complemento OSGI, etc.
- Los componentes están escritos por un único desarrollador o un equipo estrechamente integrado.
- estás siguiendo la terminología y el enfoque de algo como la arquitectura hexagonal
- un puerto de componente es donde deja el idioma local, y su sistema de tipos, detrás, cambiando a http / SQL / XML / bytes / ...
- En cada puerto se envían interfaces tipadas, en el sentido de Java / C #, que pueden tener implementaciones cambiadas para cambiar las tecnologías.
Por lo tanto, probar un componente es el mayor alcance posible en el que algo todavía se puede llamar razonablemente prueba unitaria. Esto es bastante diferente de cómo algunas personas, especialmente académicos, usan el término. No se parece en nada a los ejemplos del tutorial típico de la herramienta de prueba unitaria. Sin embargo, coincide con su origen en las pruebas de hardware; las placas y los módulos se prueban en la unidad, no los cables y tornillos. O al menos no construyes un Boeing simulado para probar un tornillo ...
Extrapolando de eso, y arrojando algunos de mis propios pensamientos,
- Cada interfaz será una entrada, una salida o un colaborador (como una base de datos).
- que probar las interfaces de entrada; llame a los métodos, afirme los valores de retorno.
- te burlas de las interfaces de salida; verifique que se invoquen los métodos esperados para un caso de prueba dado.
- que falsos los colaboradores; proporcionar una implementación simple pero funcional
Si lo hace de manera adecuada y limpia, apenas necesita una herramienta de burla; solo se usa unas pocas veces por sistema.
Una base de datos es generalmente un colaborador, por lo que se falsifica en lugar de burlarse. Sería doloroso implementarlo a mano; Afortunadamente, tales cosas ya existen .
El patrón de prueba básico es realizar una secuencia de operaciones (por ejemplo, guardar y volver a cargar un documento); confirmar que funciona Esto es lo mismo que para cualquier otro escenario de prueba; Es probable que ningún cambio en la implementación (en funcionamiento) provoque que tal prueba falle.
La excepción es cuando los registros de la base de datos se escriben pero nunca son leídos por el sistema bajo prueba; por ejemplo, registros de auditoría o similares. Estas son salidas, por lo que se deben burlar. El patrón de prueba es hacer alguna secuencia de operaciones; confirme que se llamó a la interfaz de auditoría con los métodos y argumentos especificados
Tenga en cuenta que incluso aquí, siempre que esté utilizando una herramienta de burla de tipo seguro como mockito , cambiar el nombre de un método de interfaz no puede causar una falla de prueba. Si utiliza un IDE con las pruebas cargadas, se refactorizará junto con el cambio de nombre del método. Si no lo hace, la prueba no se compilará.