Las pruebas tautológicas a veces se llaman pruebas que están muy relacionadas con la implementación subyacente, literalmente repitiéndolas paso a paso. Se les regaña regularmente y, en general, parece que los desarrolladores pueden evitarlos y reconocerlos. Bajo la presión de la administración, a veces tales pruebas ocurren retroactivamente en un intento de ponerse al día con la cobertura.
Sin embargo, hay casos complejos.
- El primer caso son pruebas que reproducen el comportamiento de las bibliotecas. Un caso típico es un cliente http de alguna biblioteca donde necesita crear un cliente, introducir cookies y encabezados en él y enviar una solicitud. No tiene sentido probar cada paso, aún puede haber métodos estáticos, nuevos y otros asesinos asesinos de pruebas, por lo que la forma más fácil es envolverlo en una clase de envoltura delgada. Las pruebas unitarias no son necesarias para tal clase. Puede probar esta clase en el contexto de las pruebas de dependencia de integración, es decir, la llamamos contra un servicio real y nos aseguramos de que la biblioteca funcione como se espera. Es importante que la clase contenedora no contenga lógica adicional que pueda probarse como parte de la prueba unitaria.
- El segundo caso son pruebas que verifican algo que no devuelve un resultado (o devuelve difuminado), respectivamente, la única forma de verificar que algo se llamó es espiar con un contador. Este es un caso válido, aunque limitado. Esto puede incluir procedimientos almacenados invocados, envío de correos electrónicos.
- El tercer caso son las pruebas de estrategias, políticas y otros patrones de comportamiento. Por ejemplo, cuando creamos un pedido, queremos obtener una entrada en la base de datos, luego él se pone en la línea de pedido y luego se escribe algo en los registros y correos electrónicos.
Es importante entender que nuestra prueba en este caso es una especificación de una regla, un comportamiento. Es decir, prescribe en qué orden se extraen los componentes, no porque los siga, sino porque los sigue. En este sentido, es lógico escribirlo de manera más abstracta: por ejemplo, si necesita llamar a varios servicios; de todos modos, en paralelo o secuencialmente, la prueba debe describir exactamente eso. Si los objetos lanzan pruebas, entonces probablemente no debería meter la nariz en los campos de este objeto. Por lo tanto, nuestra prueba puede verse casi como una implementación, o como la implementación más simple e ingenua de algún comportamiento, pero al mismo tiempo conocer la medida en detalle y no ser una tautología.
A veces, estos casos, sin embargo, fluyen entre sí. Es decir Es posible que tengamos varias llamadas a bibliotecas heredadas que realmente no devuelven nada, o intercambian incomprensiblemente con lo que, en orden, no es conocido por alguien que ha sido establecido, y no está muy claro quién "prescribe" el comportamiento a quién. Probarlo es como explicarle una ruta a un conductor de autobús, por lo que es mejor seguir el primer escenario.