TDD n'est pas une question de test, c'est une question de conception.
Loin de s'effondrer avec la complexité, elle excelle dans ces circonstances. Cela vous amènera à considérer le problème plus important en plus petits morceaux, ce qui conduira à une meilleure conception.
Ne tentez pas de tester chaque permutation de votre algorithme. Construisez simplement test après test, écrivez le code le plus simple pour faire fonctionner le test, jusqu'à ce que vos bases soient couvertes. Vous devriez voir ce que je veux dire à propos de la résolution du problème, car vous serez encouragé à simuler des parties du problème tout en testant d'autres parties, pour vous éviter d'avoir à écrire 10 milliards de tests pour 10 milliards de permutations.
Edit: je voulais ajouter un exemple, mais je n'ai pas eu le temps plus tôt.
Prenons un algorithme de tri sur place. Nous pourrions aller de l'avant et écrire des tests qui couvrent l'extrémité supérieure du tableau, l'extrémité inférieure du tableau et toutes sortes de combinaisons étranges au milieu. Pour chacun, il faudrait construire un tableau complet d'une sorte d'objet. Cela prendrait du temps.
Ou nous pourrions aborder le problème en quatre parties:
- Parcourez le tableau.
- Comparez les éléments sélectionnés.
- Changer d'éléments.
- Coordonnez les trois ci-dessus.
Le premier est la seule partie compliquée du problème, mais en l'abstraction du reste, vous l'avez rendu beaucoup, beaucoup plus simple.
La seconde est presque certainement gérée par l'objet lui-même, au moins facultativement, dans de nombreux cadres de type statique, il y aura une interface pour montrer si cette fonctionnalité est implémentée. Vous n'avez donc pas besoin de tester cela.
Le troisième est incroyablement facile à tester.
Le quatrième ne gère que deux pointeurs, demande à la classe de parcours de déplacer les pointeurs, appelle une comparaison et, en fonction du résultat de cette comparaison, appelle les éléments à échanger. Si vous avez truqué les trois premiers problèmes, vous pouvez le tester très facilement.
Comment avons-nous mené à une meilleure conception ici? Supposons que vous ayez gardé les choses simples et mis en œuvre une sorte de bulle. Ça marche mais, quand on passe en production et qu'il faut gérer un million d'objets, c'est beaucoup trop lent. Tout ce que vous avez à faire est d'écrire une nouvelle fonctionnalité de traversée et de l'échanger. Vous n'avez pas à gérer la complexité de la gestion des trois autres problèmes.
Vous constaterez que c'est la différence entre les tests unitaires et le TDD. Le testeur d'unité dira que cela a rendu vos tests fragiles, que si vous aviez testé de simples entrées et sorties, vous n'auriez plus à écrire plus de tests pour votre nouvelle fonctionnalité. Le TDDer dira que j'ai séparé les préoccupations de manière appropriée afin que chaque classe que j'ai fasse bien une chose et une chose.