TDD no se trata de pruebas, se trata de diseño.
Lejos de derrumbarse por la complejidad, sobresale en estas circunstancias. Lo llevará a considerar el problema mayor en piezas más pequeñas, lo que llevará a un mejor diseño.
No intente probar cada permutación de su algoritmo. Solo construye prueba tras prueba, escribe el código más simple para hacer que la prueba funcione, hasta que tengas tus bases cubiertas. Debería ver a qué me refiero con romper el problema porque se lo alentará a que simule partes del problema mientras prueba otras, para evitar tener que escribir 10 mil millones de pruebas para 10 mil millones de permutaciones.
Editar: quería agregar un ejemplo, pero no tenía tiempo antes.
Consideremos un algoritmo de clasificación en el lugar. Podríamos seguir adelante y escribir pruebas que cubran el extremo superior de la matriz, el extremo inferior de la matriz y todo tipo de combinaciones extrañas en el medio. Para cada uno, tendríamos que construir una matriz completa de algún tipo de objeto. Esto llevaría tiempo.
O podríamos abordar el problema en cuatro partes:
- Recorre la matriz.
- Comparar elementos seleccionados.
- Cambiar elementos.
- Coordina los tres anteriores.
La primera es la única parte complicada del problema, pero al abstraerla del resto, la has hecho mucho más simple.
El segundo es casi seguro que el objeto lo maneja, al menos opcionalmente, en muchos marcos de tipo estático, habrá una interfaz para mostrar si se implementa esa funcionalidad. Así que no necesitas probar esto.
El tercero es increíblemente fácil de probar.
El cuarto solo maneja dos punteros, le pide a la clase transversal que mueva los punteros, pide una comparación y, basándose en el resultado de esa comparación, pide que se intercambien los elementos. Si ha fingido los primeros tres problemas, puede probar esto muy fácilmente.
¿Cómo hemos llevado a un mejor diseño aquí? Digamos que lo has mantenido simple e implementado una clasificación de burbuja. Funciona, pero cuando vas a la producción y tienes que manejar un millón de objetos, es demasiado lento. Todo lo que tiene que hacer es escribir una nueva funcionalidad de recorrido e intercambiarla. No tiene que lidiar con la complejidad de manejar los otros tres problemas.
Esto, usted encontrará, es la diferencia entre las pruebas de unidad y TDD. El probador de unidad dirá que esto ha hecho que tus pruebas sean frágiles, que si hubieras probado entradas y salidas simples, ahora no tendrías que escribir más pruebas para tu nueva funcionalidad. El TDDer dirá que he separado las preocupaciones de manera adecuada para que cada clase que tengo haga una cosa y una cosa bien.