En ingeniería de software, ¿existe tal cosa como ‘escribir demasiadas pruebas’?

La “TDD” religiosa es tan estúpida y atroz, como la “POO” purista, o la visión desorientada de PM de Scrum. Sus inventores y defensores deben estar horrorizados al ver cómo TI adoptó esas indudablemente grandes ideas.

Desafortunadamente, eso es lo que verías en una típica “organización de TI” mediocre: líneas y líneas de pruebas CRUD sin sentido de DAO y DTO para garantizar el método de “cobertura”. A veces es getters y setters también. No estoy bromeando. No es que la omnipresente “arquitectura” de tres niveles en sí misma con DAO y DTO parezca muy inteligente.

Se pone “mejor”, si TDD es el motivo favorito del gerente de contratación. Prepárese para jurar lealtad a la “cobertura de prueba” durante la entrevista.

Sí hay !!
Me alegra que hayas preguntado y me permitas elaborar:

Como todo lo demás en cualquier otra disciplina de ingeniería, una prueba vale solo tanto como el valor comercial que protege (ya sea directa o indirectamente). Si pasa demasiado tiempo escribiendo pruebas que protegen solo partes de bajo valor del sistema, entonces el saldo de Costo vs Beneficio no es correcto (es decir, no se basa en el valor comercial) y, por definición, las pruebas son (relativamente hablando) redundantes en el sentir que su beneficio no justifica su costo.

Ahora, si continúa cometiendo el error anterior (escribiendo muchas pruebas que protegen partes triviales del sistema), estadísticamente está escribiendo “demasiadas” pruebas, en el sentido de que, por ejemplo, el 80% de sus pruebas solo están protegiendo 20% del valor comercial del código. Tenga en cuenta que digo que el 20% del negocio NO el 20% del código. Es posible (y en realidad altamente probable) que continúe escribiendo pruebas que protegen partes no importantes del sistema y que deje las partes importantes sin probar.

Al final, podría enfatizar que la clave aquí es el valor comercial (* no * el valor de código) de las pruebas. Por ejemplo, una prueba que se asegura de que se cumpla una restricción comercial muy importante en algunos escenarios importantes es muy útil para dedicar tiempo, pero una prueba que asegura que el campo “correo electrónico” en el Formulario de registro esté marcado como “requerido” No es tan importante y teniendo en cuenta lo apretado que suele ser el cronograma, una prueba de este tipo podría considerarse redundante (demasiadas).

Espero que esto ayude.

Sí, y puede ser un gran problema, ya que las pruebas a menudo requieren que la aplicación se comporte de una manera particular para “pasar”. Si tiene una gran cantidad de pruebas, cambiar el comportamiento de la aplicación se convierte en un gran problema, que generalmente requiere mucho más trabajo para recodificar las pruebas ahora rotas que simplemente cambiar la aplicación en primer lugar.

He estado en situaciones como esta ocasionalmente y significa que eres muy cauteloso para hacer cambios radicales en la aplicación, incluso si es necesario realizarlos, ya que tienes una gran “base instalada” de pruebas de la que preocuparte.

Por lo tanto, a menos que tenga un producto maduro con interfaces muy bien definidas, un conjunto de pruebas gigante puede ser un obstáculo. Debe tener un cuerpo de pruebas decente, pero a menudo es complicado mantener el equilibrio entre las pruebas integrales y la implementación flexible de aplicaciones.

Muy posible en diferentes niveles de prueba:

Pruebas unitarias: puede terminar dándose una falsa sensación de seguridad si ve que muchas pruebas tocan la misma línea de código cuando mira el informe de cobertura. Si la afirmación en la prueba es débil o falta, terminarás teniendo demasiadas pruebas que no hacen nada. Las pruebas en enumeraciones, getters, setters y otras pruebas superfluas no son malas, pero no deberían haberse escrito. Ya has perdido tu tiempo; no es necesario perder más tiempo quitándolos.

Pruebas funcionales: las pruebas automatizadas no son gratuitas. Cada minuto que tardan es un minuto en que el cliente no tiene su producto (suponiendo una entrega continua). Peor aún, si no tiene pruebas funcionales desglosadas a un nivel lo suficientemente pequeño (busque la pirámide de prueba), entonces tienen una mayor probabilidad de descamación. Cuando tenga pruebas de descamación, deberá hacer la llamada para enviar con ellos o detener el envío. Malo tanto para la entrega como para la calidad.

Pruebas manuales con guiones: una es demasiada. Una completa perdida de tiempo.

Hay 2 tipos de prueba, buena prueba y mala prueba. Nunca puede tener demasiadas pruebas buenas, pero una sola prueba incorrecta es demasiadas pruebas.

Las buenas pruebas son aquellas en las que cuando falla, garantiza al 100% que su código tiene un error y puede identificar el error con bastante facilidad.

Las malas pruebas son aquellas que cuando falla, usted hace / piensa / dice cualquiera de los siguientes:

• WTF, acabo de renombrar una variable privada
• Err, ya hay una prueba similar
• Voy a comentar esta prueba ahora, porque no sé lo que está haciendo; por lo tanto, no sé por qué está fallando
• Amigo, acabo de agregar un nuevo atributo a la clase A por qué las pruebas de clase E, F, G, H, I, J, K, L, M, N fallaron
• No mierda, sé que la prueba falló, pero ¿qué afirmación?
• Ok, ¿por qué esta prueba no falló antes? Funcionó en mi escritorio
• Por amor de Dios, ¿me tomó 10 minutos escribir el código y 1 hora ejecutar la prueba de la unidad?
• Maldición, ahora tengo que cambiar todas esas pruebas porque refactoricé un método privado.

Desafortunadamente, todos tenemos demasiadas pruebas.

Sí, es fácil escribir pruebas tontas, sin sentido y redundantes.

Suponga que un programa toma un entero como entrada. Suponga que su probador decide escribir una prueba para cada entrada posible. Ahora terminas escribiendo un número infinito de pruebas cuando probablemente no haya tanta variabilidad en cómo funciona el programa.

Es imposible demostrar que un software dado no tiene errores. Entonces, realmente podrías escribir pruebas infinitas y todavía no sabrías que no hay errores. En algún momento tienes que decir parar. La pregunta es cuándo.

escribir pruebas cuesta dinero. Tienes que gastar esfuerzo escribiendo la prueba. Entonces tienes que gastar esfuerzo para mantener esas pruebas

Los errores cuestan dinero. Un error detectado durante el desarrollo es más económico de reparar que el mismo error encontrado en la producción. Además, los errores encontrados por su cliente pueden generar costos de oportunidad. Su cliente podría simplemente deshacerse de usted.

Entonces, la cantidad de pruebas es una cuestión de ROI. Usted prueba lo suficiente para detectar los errores más costosos temprano. Cuando el costo de escribir las pruebas excede el costo de los errores que encuentran las pruebas, deja de hacerlo.

Si. Debes centrarte en escribir pruebas que agreguen valor. Supongo que puede parecer difícil argumentar en contra de una cobertura de prueba del 100%, pero es importante tener en cuenta que el código de prueba, como cualquier otro código, requerirá mantenimiento. Con el tiempo, el mantenimiento de pruebas inútiles puede conducir a una succión de tiempo.

El código heredado puede ser muy difícil de probar si no se escribió teniendo en cuenta las pruebas. El resultado de esto a menudo es que terminas con un código de prueba que es un orden de magnitud más complejo que el código bajo prueba. Esta es una señal de alerta en términos de mantenimiento, especialmente si las pruebas agregan un valor mínimo más allá de ayudar a la cobertura de su código.

Soy un gran defensor de las pruebas automatizadas, pero creo firmemente que para que las pruebas automatizadas sean útiles, el código bajo prueba debe redactarse teniendo en cuenta las pruebas. Si el código es muy difícil de probar, debe equilibrar el esfuerzo de escribir las pruebas, incluido el mantenimiento, con la utilidad de las pruebas al final. En muchos casos, será mucho mejor refactorizar el código para que sea más comprobable que lidiar con la penalidad de crear pruebas frágiles para el código “no comprobable”.

El objetivo de TI debe ser escribir código que sea tan fácil de consumir desde una prueba unitaria como desde cualquier otro consumidor (vista, servicio, etc.). En general, las pruebas de código correctamente desacoplado a menudo agregan un gran valor, además de ser fáciles de escribir y mantener.