Blog ENI : Toute la veille numérique !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Gestion des tests logiciels
  3. Organiser les tests unitaires
Extrait - Gestion des tests logiciels Bonnes pratiques à mettre en oeuvre pour l'industrialisation des tests (2e édition)
Extraits du livre
Gestion des tests logiciels Bonnes pratiques à mettre en oeuvre pour l'industrialisation des tests (2e édition) Revenir à la page d'achat du livre

Organiser les tests unitaires

Organisations possibles

Dès lors que nous parlons de tests unitaires, nous présupposons que ceux-ci sont réalisés en phase de réalisation d’un logiciel.

1. Le développeur livré à lui-même, seul ou en équipe

Qu’il soit une équipe à lui tout seul ou dans une équipe dans laquelle le chef de projet MOE n’est pas familiarisé avec l’organisation des tests unitaires, le développeur est dès lors livré à lui-même pour gérer ses tests. Cette situation doit être évitée autant que possible.

S’il est tout seul, le développeur fait alors office de chef de projet MOE très théoriquement (car il n’a pas nécessairement l’expérience de cette fonction) et doit organiser son travail de manière autonome.

Deux tâches permettront alors de cadrer cette organisation.

a. Hiérarchiser son travail

Cette préconisation peut paraître triviale mais il nous a semblé nécessaire de l’indiquer comme prérequis à l’organisation des tests unitaires.

Le développement de la solution logicielle est généralement hiérarchisé, c’est-à-dire ordonnancé de manière cohérente en fonction des dépendances techniques du développement ainsi que d’une priorisation des fonctionnalités fournies par l’expression des besoins.

Nous conseillons de tester unitairement les développements en respectant cet ordre en commençant par les "bouts de code" mutualisés et réutilisés en plusieurs lieux du logiciel.

Une fois ces parties communes fiabilisées, passez aux couches logicielles appelantes. Cette organisation, logiquement, fera que le développeur commencera par tester les couches logicielles de bas niveau en premier (les accès aux données), puis les couches intermédiaires (middleware) pour en dernier tester unitairement la couche de présentation de l’information, l’interface homme- machine (IHM), s’il y en a une, ou bien les paramètres d’entrée, s’il n’y en a pas.

Puis réitérez ce principe brique après brique, jour après jour.

En suivant ainsi la structure...

Tests unitaires élémentaires

Pour plus de détails, l’auteur vous renvoie à un précédent ouvrage pour ce qui est des tests unitaires élémentaires des applications web : "Tester une application web" aux Éditions ENI également, dans la collection Expert IT.

La présente section reprend de manière sommaire les tests unitaires pouvant être conduits sur une interface graphique, que celle-ci soit une application web ou un client lourd.

La section qui suivra se focalisera sur une autre problématique : tester unitairement un flux de données ou un traitement automatique sans interface graphique.

1. Tester un écran ou un formulaire

Nous parlerons d’écran pour les clients lourds et de formulaire pour désigner leur équivalent dans le monde des clients légers.

a. Libellés statiques

Par libellé statique on entend toute partie textuelle de l’interface (écran ou page web) qui n’a pas pour origine une donnée issue d’une base et qui aurait un rôle métier.

Ce libellé est dit statique car il est relativement stable d’une exécution à une autre, tout au plus, il pourra être traduit par une fonction de changement de langue de l’interface. Il n’est d’ailleurs pas possible d’interagir avec lui.

Pour l’essentiel, il sera demandé aux développeurs de tester :

  • Le respect de la charte graphique (police, graisse, couleur, style…),

  • L’orthographe et la présence de caractères spéciaux,

  • Le sens sémantique : le libellé doit avoir un sens pertinent.

Le test en lui-même consiste à exécuter l’application autant de fois que nécessaire pour en afficher tous les libellés statiques de tous les écrans possibles.

b. Libellés dynamiques

À l’opposé des libellés statiques, les libellés dynamiques correspondent à une présentation d’une donnée issue d’une base. Le test consiste donc à exécuter l’application pour autant de lieu où une donnée dynamique est affichée et de simultanément lire la donnée par un autre biais pour en comparer les valeurs.

Des conversions peuvent être effectuées...

Formaliser les tests unitaires

1. Dans un projet géré en V

a. Pourquoi formaliser les tests unitaires ?

Dans une organisation d’un projet selon le cycle en V dite "classique", les tests unitaires sont la tâche ultime du développeur avant livraison de sa production à une cellule de tests techniques (ou à la MOA directement parfois).

Ce jalon du projet est particulièrement critique et cette livraison est caractérisée par un ensemble de livrables précis :

  • Les sources de l’application et/ou l’exécutable associé et tout composant logiciel utile.

  • Une fiche de livraison, document listant les items de ladite livraison.

  • Parfois un guide d’installation ou/et d’exploitation.

  • Idéalement, un dossier de conception technique détaillant la solution développée ainsi qu’un dossier d’architecture.

Une équipe d’exploitation installera le logiciel, le paramétrera, préparera aussi la ou les bases de données par extraction de la production… autant d’opérations techniques pour lesquelles le guide d’installation, le dossier d’exploitation ou le dossier d’architecture technique pourra être utile.

Mais l’étape qui suit la livraison est le déploiement pour une recette : seules l’application elle-même et la fiche de livraison ont un intérêt pour mener des tests.

La fiche de livraison notamment décrira le périmètre de ce qui est livré ce qui permet une première vérification relativement aux tests prévus : le CP Recette peut déjà avoir une première visibilité de couverture, notamment identifier les fonctionnalités absentes ou nouvelles qui présentent des risques plus importants.

En revanche, le CP Recette n’a alors pas de visibilité sur le périmètre des tests unitaires, ce qui a été fait et surtout ce qui n’a pas pu l’être.

La question se pose alors de savoir comment une équipe de développement et plus précisément le CP MOE peut communiquer en aval de la réalisation sur ce sujet.

Bien sûr, il n’y a pas toujours nécessité à faire cela et c’est le contexte du projet qui permet de savoir...

Risques projet liés à la gestion des tests unitaires

1. Impact sur la charge

a. Vers une augmentation de la charge de réalisation ?

Comme nous l’avons évoqué dans une section précédente, le chef de projet MOE doit anticiper lors de son évaluation de charges qu’une part de l’activité sera consacrée aux tests unitaires : nous avions donné à titre indicatif le ratio de 20 à 33 %.

Bien évidemment, la formalisation des tests unitaires nécessite de rédiger un support (soit un rapport de tests unitaires, soit d’enrichir le backlog en Méthode SCRUM) ce qui représente un effort supplémentaire.

Mais il serait faux de croire qu’en s’affranchissant de tester l’on gagnera du temps car l’absence de tests unitaires conduira à trouver des anomalies ultérieurement ce qui coûtera plus cher au global.

On pourra argumenter alors que l’effort de tests est fait ailleurs et sur une enveloppe budgétaire pour laquelle le CP MOE n’a pas de responsabilité… mais c’est un débat stérile que nous n’aborderons pas ici. Le principe de base est que toute économie de charge doit être réalisée le plus tôt possible et qu’un projet est géré par une équipe unique dans un objectif commun.

Même...