Le TDD s'associe souvent à des tests unitaires. Mais cela n'est pas toute la vérité et surtout cela a tendance à guider les gens dans une impasse.

Au delà des exemples basiques du TDD, regardons comment on s'y prend sur un vrai projet.

Difficile de développer une story en TDD? Les tests sont écrits après le code? Le code qui s'intègre avec d'autres systèmes est peu testé ou testé avec des mocks? Il y a beaucoup de tests à modifier pour refactorer du code? Voici quelques symptômes qui peuvent venir du même mal - une conception trop "unitaire" des tests et du TDD.

Certes, nous voulons des tests unitaires pour le besoin de reproductibilité, rapidité, maintenabilité etc. Mais ceci n'est ce qui nous importe lorsqu'on développe une nouvelle fonctionnalité où nous avons plutôt besoin de découvrir la réalité des choses, les problèmes d'intégration etc.

Comment allier les deux besoins? Que peut-on se permettre dans la phase de construction? Que fait-on avec les tests peu maintenables dans la CI? Les mocks, sont ils bien ou pas? Quels tests pour l'intégration avec "l'externe"? Puis-je faire avec mon projet "legacy"? Les réponses vous attendent dans cette session.