J'ai constaté que le TDD fonctionne mal en ce qui concerne les systèmes émergents. Développeur de jeux vidéo, j'ai récemment utilisé TDD pour créer un système qui utilise plusieurs comportements simples afin de créer un mouvement réaliste pour une entité.
Par exemple, il existe des comportements qui vous obligent à vous éloigner de zones dangereuses de types différents et des comportements qui vous obligent à vous diriger vers des zones intéressantes de types différents. La fusion de la sortie de chaque comportement crée un mouvement final.
Les entrailles du système ont été mises en œuvre facilement, et TDD a été utile ici pour spécifier la responsabilité de chaque sous-système.
Cependant, j'ai eu des problèmes pour préciser comment les comportements interagissaient et, plus important encore, comment ils interagissaient au fil du temps. Souvent, il n’y avait pas de bonne réponse, et bien que mes tests initiaux aient été concluants, le contrôle de la qualité pouvait continuer à trouver des cas extrêmes dans lesquels le système ne fonctionnait pas. Pour trouver la bonne solution, je devais parcourir plusieurs comportements différents, et si je mettais à jour les tests chaque fois pour refléter les nouveaux comportements avant de vérifier qu'ils fonctionnaient dans le jeu, j'aurais peut-être fini par les rejeter à maintes reprises. J'ai donc supprimé ces tests.
J'aurais peut-être dû subir des tests plus rigoureux prenant en compte les cas critiques QA découverts, mais lorsque vous avez un système comme celui-ci qui repose sur de nombreux systèmes de jeu et de physique, et que vous traitez des comportements au fil du temps, cela devient un peu un problème. cauchemar pour spécifier exactement ce qui se passe.
J'ai presque certainement commis des erreurs dans mon approche et, comme je l'ai dit pour les entrailles du système, TDD a fonctionné de manière brillante et a même pris en charge quelques refacteurs d'optimisation.