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.         

Cet article est un résumé du chapitre 2 du livre JUnit, mise en oeuvre pour automatiser les tests en Java, écrit par Benoît Ganthaume et publié aux éditions ENI.

Le point de départ de la création d’un logiciel est l’identification du besoin client (comprendre ici l’utilisateur et non l’acheteur), le résultat final est le produit. Les 5 phases du développement comportant inévitablement des erreurs émanant des différents acteurs impliqués, le test répond à un double objectif : ne pas les reproduire et valider chaque étape de production. Il donne un feedback sur la qualité via une boucle de rétroaction.

Le concept de qualité est influencé par notre perception, ses critères varient en fonction du point de vue de chaque acteur (client, direction, équipe de développement). La notion de logiciel « juste assez bon » implique des compromis entre les parties du projet, ainsi qu’une gestion des risques orientée client : les défauts l’impactant fortement sont à corriger en priorité.

Les tests manuels nécessitent une personne pour exécuter et contrôler le comportement de l’application. Leur suivi permet d’établir des indicateurs de qualités. Leurs avantages sont la mise en situation réelle, la validation in situ, le faible coût de mise en place et la flexibilité inhérente au facteur humain. A contrario, certaines erreurs sont difficiles à valider, leurs exécutions sont couteuses et les résultats nécessitent du temps. Enfin, le contrôle humain engendre des risques d’erreurs.

Les tests automatiques sont gérés par un programme qui les exécute automatiquement ou sur demande. L’automatisation relève de l’intégration continue, et génère des rapports de tests automatiques.  Couteux à mettre en place, moins souples que les tests manuels, leurs coûts et délais d’exécution restent faibles, constants et réguliers, facilitant leurs réexécution.

Le choix entre ces types de tests implique un équilibre en fonction du contexte de l’application et de sa complexité.

L’automatisation accentue la vélocité du développement, l’équipe garde une vision continue de l’impact de son travail. Le retour sur investissement est élevé, les couts et les temps de correction sont réduits. C’est un facteur clef de compétitivité s’ils sont entretenus et améliorés en permanence.

Les tests automatiques doivent êtres rapides, indépendants les uns des autres, répétables, auto-validant, et écrit avant le code.