Lo más probable es que haya llegado a su cifra de 65 mil millones de pruebas calculando todas las combinaciones posibles de entradas en el sistema bajo prueba, o calculando la complejidad ciclomática y suponiendo que se debe escribir una prueba para cada una de estas rutas de ejecución únicas.
No es así como se escriben las pruebas reales, porque como lo han indicado otros afiches y comentaristas, el poder técnico requerido para ejecutar 65 mil milloneslas pruebas son asombrosas. Esto sería como escribir una prueba que ejercita un método para agregar dos enteros conectando cada permutación posible de dos valores de 32 bits y verificando el resultado. Es una locura absoluta. Debe trazar la línea e identificar un subconjunto de todos los casos de prueba posibles, que entre ellos garantizarían que el sistema se comportará como se espera en todo el rango de entradas. Por ejemplo. prueba agregar algunos números "normales", prueba algunos escenarios de números negativos, prueba límites técnicos como escenarios de desbordamiento y prueba cualquier escenario que pueda dar lugar a un error. Como se mencionó, estos diversos tipos de pruebas ejercen "clases de equivalencia"; le permiten tomar una muestra representativa de las posibles entradas, junto con cualquier "valor atípico" conocido,
Considere uno de los katas de código básico, el generador de números romanos. La tarea, que se realizará utilizando técnicas TDD en un estilo de "dojo", es escribir una función que pueda aceptar cualquier número del 1 al 3000 y producir el número romano correcto para ese valor numérico.
No resuelve este problema escribiendo 3000 pruebas unitarias, una a la vez, y pasándolas sucesivamente. Eso es locura; el ejercicio normalmente toma entre una y dos horas, y estarías allí durante días probando cada valor individual. En cambio, te vuelves inteligente. Comienza con el caso base más simple (1 == "I"), implementa eso usando una estrategia de "código mínimo" ( return "I";), y luego busca cómo el código que tienes se comportará incorrectamente en otro escenario esperado (2 == " II "). Enjuague y repita; Lo más probable es que haya reemplazado su implementación inicial con algo que repita el carácter "I" tantas veces como sea necesario (como return new String('I',number);). Obviamente, pasará una prueba para III, por lo que no se molestará; en su lugar, escribe la prueba para 4 == "IV", que sabe que la implementación actual ganó '
O, en un estilo más analítico, examina cada decisión condicional que toma el código (o debe ser) y escribe una prueba diseñada para ingresar el código para cada posible resultado de cada decisión. Si tiene 5 declaraciones if (cada una con una rama verdadera y falsa), cada una de ellas completamente independiente de la otra, codifica 10 pruebas, no 32. Cada prueba estará diseñada para afirmar dos cosas sobre una posible decisión particular; primero que se toma la decisión correcta, y luego que el código ingresado dada esa condición es correcto. Usted no codificar una prueba para cada posible permutación de decisiones independientes. Si las decisiones son dependientes, entonces debe probar más de ellas en combinación, pero hay menos combinaciones de este tipo porque algunas decisiones solo se toman cuando otra decisión tuvo un resultado particular.