Les Agilistes de ce monde sont au fait de l’importance des tests automatisés pour assurer la pérennité d’un projet informatique. En fait, tout développeur qui a tenté la pratique du TDD et qui a réussi à inclure cette pratique dans son travail au quotidien découvre rapidement le sentiment de puissance qui en résulte. Ce sentiment de puissance prend sa source dans le fait que le développeur a beaucoup plus d’assurance et de confiance dans le logiciel qu’il développe. Le fait d’avoir plus d’assurance et de confiance laisse une meilleure impression au client et inévitablement résulte en une équipe plus heureuse. Cependant, afin de toujours s’assurer de livrer le maximum de valeur au client, il est parfois nécessaire d’ajuster le niveau de couverture des tests selon le contexte du projet. Dans le cadre du développement d’une ‘preuve de concept’ (prototype), par exemple, il y a de fortes chances que le développement du prototype ne se poursuive pas pendant des mois. Le système ayant une taille réduite, l’équipe peut limiter la couverture des tests unitaires à certaines parties critiques du code car il est moins probable que le système régresse en qualité sans que l’équipe découvre rapidement une anomalie. Ainsi, s’appuyer simplement sur quelques tests manuels peut être un choix judicieux lorsque l’équipe a peu de temps pour développer les fonctionnalités requises afin de répondre aux objectifs d’affaires du prototype, à condition bien sûr de ne pas reprendre le développement du système à partir du prototype (ce qui se produit malheureusement dans la plupart des cas). Dans un projet Web MVC, par exemple, une équipe pourrait décider de tester uniquement le cœur du domaine d’affaires sans tester les contrôleurs ni les vues. Le fait de couper sur les tests sous prétexte qu’on veut livrer plus de fonctionnalités d’un système dont le développement se déroule sur plusieurs mois à l’aide d’une approche Agile de développement logiciel est un choix qu’on pourrait qualifier de risqué. Un tel choix peut ralentir sérieusement l’avancement du projet car le risque d’endommager les bouts de logiciel déjà livrés sans test augmentera de façon quasi exponentielle sprint après sprint. En plus de provoquer l’inverse de l’effet escompté, ce genre de choix augmentera significativement le coût de développement du système. De plus, cette diminution de qualité créera nécessairement des tensions entre le client et l’équipe, ce qui nuira significativement au plaisir de développer du logiciel. On constate ainsi que la définition de « Just Good Enough » pour les tests varie significativement d’un contexte de développement à l’autre, d’où l’importance de l’établissement d’une définition de ‘Terminé’ bien adaptée à la situation.
