Organiser les tests unitaires

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...

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 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...

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 :

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...

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.