Cet article est un résumé du chapitre 3 du livre JUnit, mise en oeuvre pour automatiser les tests en Java, écrit par Benoît Ganthaume et publié aux éditions ENI.
__________________________________
Classiquement, l’analyse d’un projet s’effectue selon le triptyque de variables interdépendantes : coût, qualité, périmètre.
Les tests automatiques font circuler la connaissance entre les acteurs, leur permettent de garder une visibilité sur l’évolution du projet en validant la cohérence et la testabilité de l’architecture tout en objectivant les exigences. Ils fournissent un indicateur de progression et assurent contre les régressions du code. En fonction de la méthodologie de travail, les quatre activités fondamentales (recueil des besoins, conception, codage et tests) prennent des places et finalités différentes :
Les méthodes linéaires :
Le modèle de la cascade: Chaque erreur aura un coût de correction plus élevé lors de l’étape suivante, imposant ainsi la validation totale d’une étape avant de la franchir. Les tests arrivent uniquement en fin de chaîne, doivent couvrir totalement le code et idéalement être effectué par des personnes qui ne l’ont pas écrit. Les phases préliminaires du développement (conception, documentation, prototype), ainsi que l’implication du client sont fondamentales.
Le cycle en V : Conçu sur le modèle de la cascade, il pallie au rôle tardif des tests dans ce dernier : Chaque étape de la cascade doit être validée par un type de test particulier : Les tests unitaires sont l’affaire des développeurs, les tests d’intégration (validant le fonctionnement temporel ou architectural de l’application après mise en commun des différentes parties) garantis par les architectes. La Maîtrise d’oeuvre (MOE) livre les tests de validation fonctionnels (coté client) et de performance, la Maîtrise d’ouvrage (MOA) s’occupe des tests de recette, vérifiant le comportement de l’application dans des conditions réelles.
Les méthodes itératives et incrémentales: Approches agiles
La spirale, pilotée par les risques, est la première formalisation agile. Elle se découpe en quatre phases validant un incrément, pour conduire à l’itération suivante. L’évaluation initiale classique n’est plus applicable, l’identification des risques devient primordiale.
Le “Rational Unified Process” (RUP) fait intervenir tous les types d’activités au cours de phases (inception, élaboration, construction, transition) destinées à réduire progressivement les risques et se découpant en itérations. Le RUP définit différents rôles, dont celui de testeur, qui évolue au cours des différentes phases. Les tests automatiques, bien qu’optionnels, apportent de précieux atouts à chaque rôle.
La méthode SCRUM s’appuie sur des itérations de durées fixes (sprints) destinées à faire progresser le logiciel par ajouts successifs, mais ne prévois pas de méthodes de test.
L’eXtreme programming (XP) intègre gestion de projet et pratiques d’ingénierie, systématisées et poussées à l’extrême, permettant d’assurer une faible évolution du coût de changement. L’XP s’appuie sur le code pour gérer l’ensemble du projet (documentation et tests compris). Généralement, chaque itération (devant aboutir sur la livraison d’un incrément fonctionnel) se décompose en conception, test puis développement. Le code actif est donc écrit pour faire passer un test précis. La conception se doit d’être simple, les tests automatiques et leurs intégration continue, assurant une protection contre la régression. Les tests de recette constituent un contrat client à remplir. L’équipe, composée de différents rôles, communicant via un vocabulaire commun, est collectivement responsables du code et des tests. Les tests occupent une place fondamentale en XP, leur nombre et leur fréquence apportent une indication sur la charge et le rythme de travail de l’équipe.