Ces dernières semaines durant mon développement ou autour d’un autre binôme à Pyxis, j’ai été confronté à cette discussion qui trainait et qui au final ralentissait le développement : Membre de l’équipe 1 : A ton avis, c’est un test d’intégration ou un test unitaire? Membre de l’équipe 2 : ouf, y’a un fichier XML à utiliser, je vois pas comment s’en passer sans perdre le sens du test, çà doit forcement être un test d’intégration. Membre de l’équipe 1 : Oui mais, il y a pleins de traitement différents que j’aimerais tester unitairement alors faire un test d’intégration avec le fichier… Membre de l’équipe 2 : bon bah on va faire deux tests alors. Mais on fait quoi en premier? Membre de l’équipe 1 : Bah c’est évident, on commence par l’unitaire. Membre de l’équipe 2 : Et on fait comment pour le fichier? Constat A partir de ce point, on tourne en rond. On cherche à tester unitairement pour se rendre compte que l’on n’arrive pas à isoler ce maudit fichier. Pattern De ce que j’ai pu observé dans les différentes situations auxquelles j’ai été confrontées, le problème était le même. La question ne venait pas de la façon d’aborder les tests du composant mais bien le composant en lui même. Celui-ci dépendait d’une ressource (fichier XML, base de données, Service distant) lui fournissant des services de données. Ce même composant proposait un certain nombres de routines de traitement de ces mêmes données. Logique + données, pourquoi ne pas séparer? Au final, la résolution passait par une séparation de ces deux aspects du comportement. On extrait la partie accès aux données et la partie traitement. Rien de novateur, là dedans, ce qui l’est davantage pour moi (et je pense que vous en conviendrez), c’est que les tests ont facilité de détecter ce pattern et par expérience désormais si j’entend un développeur se posait la question : Test d’intégration ou test unitaire? je lui suggérerais en tout premier lieu de revoir le code ciblé par le test( ou l’idée qu’il s’en faisait en TDD).
