El otro día, leyendo una página web sobre una aplicación encontré lo siguiente:
Robusto: Más de 230 pruebas Junit.
La primera pregunta que se plantea es bastante obvia: ¿Podemos medir el grado de robustez o fiabilidad de un sistema mediante el número de pruebas?.
No. Un ejemplo muy claro, aunque tal vez un poco extremo. Imaginemos el
siguiente código (que sirve tanto para C como para Java).
int factorial(int n) {
if (n == 1)
return n;
return n * factorial(n-1);
}
Supongamos que escribo 100 pruebas para comprobar los 100 primeros factoriales. ¿Puedo asegurar que el código anterior es robusto?. No. en cuanto reciba un 0 o un número negativo fallará a pesar de sus 100 (o 11000) pruebas.
Otra pregunta, tal vez no tan obvia, es si la robustez o fiabilidad de un sistema está garantizada únicamente por pruebas unitarias.
No. Un ejemplo muy claro lo encontramos en las aplicaciones web. Con pruebas
tipo JUnit, u otra herramienta similar, difícilmente podremos comprobar la respuesta del sistema a un gran número de peticiones concurrentes de distintos clientes, ni si el sistema es capaz de seguir funcionando o se colapsa.
La gran pregunta que habría que responder es: ¿Como podemos garantizar la robustez del sistema?. Lo cual nos lleva a plantearnos: ¿y qué es la robustez?.
Habrá que seguir con esto.
4 comments:
Bien, en realidad lo que ocurre es que normalmente las pruebas unitarias de Junit son de tipo "white box", es decir, conociendo el código, por lo que se suelen probar los casos extremos de las condiciones, etc.
Por otro lado, está claro que la única forma de probar la robustez de la aplicación es mediante pruebas de carga, simulando (por ejemplo en entorno web) un gran número de peticiones.
Puedo asegurar, por experiencia, que no hay forma de verificar, que un sistema es totalmente robusto. Puedes dormirte en los laureles porque todo funciona correctamente durante un año, y llega un usuario y usa tabulador en vez de enter en un sitio muy concreto y la hemos liado. Solo en trozos pequeños de código puede verificarse la robustez del mismo, en el resto hay que verificar todas las posibles variantes y eso suele ser imposible.
Como dice juanjo, son pruebas tipo "white box" y sabemos lo que hará el código. Así que probaremos, además de lo que tiene que hacer cuando todo va bien, lo que hará cuando no todo vaya bien. Ej: nulos, arrays vacios, datos desordenados, etc. etc. No tiene mucho sentido, como pones tú de ejemplo, hacer el mismo test 1000 veces con números distintos.
Además, por muchas pruebas que haya, nunca tendremos la certeza 100% de que no fallará nunca. Pero lo que se pretende es que sea robusto, que falle lo menos posible y si falla saber reaccionar.
Y con JUnit sí que se pueden simular varios usuarios simultaneos y medir tiempos. Se puede hacer con JUnitPerf que es una extensión del mismo.
De todas formas, la afirmación inicial ("Robusto: Más de 230 pruebas Junit") me parece un poco absurda. Sí que hay que hacer todo el testing posible y que cubra el mayor número de casos posibles. Pero de ahí a decir que son 230... supongo que querrán decir "muchas" pruebas.
Hacer la misma prueba con distintos números pero la misma intención es absurdo....además si diseñas una batería de 1100 pruebs sin que esté el 0 (como representante del valor crítico) es que tienes un problema
Post a Comment