Accueil > Divers > Tests unitaires, d’intégration, fonctionnel, métier : comment les définir ?

Tests unitaires, d’intégration, fonctionnel, métier : comment les définir ?

Le champ sémantique de ces termes a évolué au fil du temps, conduisant à un certain flou et parfois des incompréhensions. Nous allons dans cet article apporter différents éclairages sur la terminologie du test, en espérant que cela pourra contribuer à une meilleure compréhension entre experts !

Situons le contexte

Le niveau processus

Un logiciel utilisé dans une entreprise a pour vocation de servir ses utilisateurs dans l’exécution des processus métier ou support. Au niveau le plus élevé, le fonctionnement d’une entreprise peut en général être décrit par des processus. Certains de ces processus ont pour objectif premier d’apporter de la valeur aux clients de l’entreprise (processus de commande et livraison, processus de service après vente, etc.), d’autres y contribuent moins directement mais restent pour autant nécessaires (processus d’approvisionnement, processus de paie des collaborateurs, etc.).

Ces processus sont caractérisés par des échelles de temps pouvant aller de quelques minutes à quelques années, l’ordre de grandeur typique étant de quelques jours. Ils font intervenir dans la majorité des cas plusieurs acteurs (de l’entreprise ou externes).

Le niveau cas d’utilisation

A certaines étapes de ces processus, un acteur sera susceptible d’utiliser un logiciel. Dans l’exemple du processus de commande et livraison, nous avons par exemple des étapes informatisées :

  • La prise de commande
  • La préparation de la commande
  • Le contrôle de la commande
  • L’expédition
  • La facturation

La plupart du temps, chacune de ces étapes correspondra à la notion de cas d’utilisation du logiciel. Le niveau de granularité est plus fin que pour le processus, et l’échelle de temps limitée à quelques minutes. Lorsqu’un cas d’utilisation a été déroulé à une étape du processus, l’étape suivante pourra être déclenchée immédiatement,  ou de manière asynchrone. Dans notre exemple, après la prise de commande, celle-ci est ajoutée dans la liste d’attente de l’entrepôt ou de l’atelier, et sera traitée dans un délai fonction de la charge de travail de ce service à l’instant présent.

Tout cela reste approximativement  valide avec la notion de User Story, toujours est-il que cela n’a effectivement pas d’importance pour notre sujet, les tests.

Le niveau opération

Un cas d’utilisation est constitué d’un enchaînement d’opérations unitaires, matérialisées (ou non) dans le logiciel par un changement d’écran. Par exemple pour la prise de commande, nous aurons en général :

  • Identification du client
  • Vérification de l’adresse de livraison et de l’adresse de facturation
  • Enregistrement des produits ou services commandés
  • Finalisation de la commande avec annonce du prix
  • Validation

Nous avons encore une fois délibérément simplifié, en omettant toutes les variantes : nouveau client, rupture de stock d’un produit, annulation avant l’aboutissement, réduction de la commande après annonce du prix jugé trop élevé, etc.

Lien avec les tests

Tests métiers et fonctionnels

Les définitions précédentes conduisent naturellement à une correspondance avec les types de tests.

Le test métier consistera à simuler l’exécution d’un processus avec le logiciel alors que le test fonctionnel sera ciblé sur le niveau de granularité du cas d’utilisation. De fait, le processus nécessitant l’exécution d’une série d’étapes, et donc d’une série de cas d’utilisation, le test métier consiste à assembler des tests fonctionnels, avec des données de tests en cohérence.

Établir le lien entre les cas d’utilisation et les processus métiers apporte des bénéfices certains :

  • Réutilisation des tests fonctionnels pour construire les tests métiers
  • Dans une démarche de développement itérative : vérification de la capacité du produit développé à instrumenter les processus effectuée plus tôt (par rapport à une démarche type cascade)
  • Garde-fou concernant la prise en compte dans l’organisation de l’entreprise de nouveaux processus liés au logiciel (administration et paramétrage le plus souvent)

Et les tests unitaires dans tout cela ?

Dans le découpage proposé, le lien avec les tests d’intégration et les tests unitaires est beaucoup moins évident. Qu’en est-il ? Peut-on relier ces tests avec la notion d’opération précédemment mentionnée ?

La conception

Pour aller plus loin, nous avons besoin d’une machine à remonter le temps. Cela tombe bien, H.G. Wells m’a prêté la sienne. Utilisons-la pour revenir dans les années 1970/1980.

Développer un logiciel d’entreprise nécessite de faire collaborer une équipe de plusieurs personnes. Par conséquent, le travail à réaliser doit être découpé en morceaux de telle sorte que ces unités d’œuvre puissent être réparties entre les membres de l’équipe projet. Dans le domaine du développement logiciel, ce travail d’organisation et de découpage du code en blocs ou modules correspond à ce qui est couramment appelé conception (il s’agit d’une vue simplifiée puisque le travail de conception a aussi pour objectif de produire un code maintenable et performant).

L’unité d’œuvre utilisée dans ce découpage est le plus souvent l’écran ou l’opération.

Le développement et les tests unitaires

Lorsque le découpage a été réalisé,  des tâches unitaires de développement sont affectées aux personnes concernées, qui les réalisent. Bien entendu, le programmeur doit s’assurer  que le code qu’il livre compile et fonctionne correctement. Comme il s’agit d’une unité d’œuvre, il est logique de parler de test unitaire.  Le niveau de granularité du test unitaire se trouve être un écran ou une opération.

En étant malin, le test unitaire pourra être une portion de test fonctionnel, ce qui d’une part évitera au développeur de se poser des questions, et d’autre part apporte une économie : le même cas de tests servira deux fois !

L’intégration

Pour des raisons de maintenance, nous avons besoin de structurer et d’organiser le code, ce qui induit des dépendances plus ou moins directes entre les unités d’œuvre, comme par exemple la navigation d’un écran vers un autre, ou la factorisation de portions de code communes entre écrans.

Lors du développement de l’unité d’œuvre A, son éventuelle dépendance avec B sera gérée par le développeur avec un bouchon (ou un objet bidon). Il conviendra ultérieurement dans le processus du projet de vérifier qu’en remplaçant le bouchon par le véritable code de B, cela fonctionne toujours. C’est ce que l’on pourrait appeler le test d’intégration !

Nous avons un autre type de tests d’intégration : lorsque l’application communique avec d’autres systèmes (par exemple l’application de comptabilité dans notre exemple d’application de gestion des commandes et livraisons), le développement se fait avec un bouchon de cet autre système. En effet, il serait lourd d’avoir dans chaque environnement de développement  la totalité des composants de l’environnement de production.

Dans ce cas, il convient à un moment ou un autre de tester l’intégration avec les systèmes externes, ce qui convient à une autre sorte de test d’intégration.

Seulement ces définitions ne correspondent pas à celles habituellement utilisées.

Où il est question d’architecture

Les architectures en couche

Afin de faciliter la maintenance des applications de taille importante, le design pattern d’architecture en couches est très souvent appliqué. Il s’agit, de manière très schématique, d’organiser le code en fonction des catégories suivantes : code d’IHM, code métier, code de persistance.

L’un des intérêts de ce découpage est que les développeurs peuvent être spécialisés dans chacune des couches de l’application. Les technologies utilisées sont souvent différentes et nécessitent des compétences différentes. En pratique, les équipes de développement sont rarement structurées ainsi.

Le test séparé de chaque couche

Le code correspondant à un cas d’utilisation ou à une user story est ventilé en fonction de l’architecture. Dans le cas d’une équipe avec des développeurs spécialisés pour chaque couche, chaque développeur doit pouvoir tester unitairement le code qu’il réalise. Il est de ce fait amené à bouchonner les couches adjacentes !

Le test d’intégration

Le test d’intégration, dans ce contexte, consiste à tester le cas d’utilisation depuis l’IHM en traversant toutes les couches.

Mais cette manière de procéder a-t-elle du sens dans le cas d’une organisation où chaque développeur  réalise le code de toutes les couches pour sa tâche ?

En fait, dans un projet comportant plusieurs centaines ou milliers de tests automatisés, le temps d’exécution de ces tests peut dépasser une heure. Cela décourage souvent les développeurs d’exécuter toute la batterie de tests avant de commiter. Afin de réduire le temps d’exécution des tests, la base de données est souvent bouchonnée. Le test d’intégration devient alors un test avec la véritable base de données, comme si cette base de données était un système externe.

Conclusion

Nous avons vu apparaître différentes manières de définir les tests unitaires et les tests d’intégration. Cela contribue à maintenir une confusion dans le vocabulaire. Le même cas de test peut très bien être utilisé comme test unitaire, test d’intégration et test fonctionnel, et lorsque c’est possible, le test unitaire en est d’autant plus pertinent.

L’automatisation des tests, bien que nécessitant un investissement important, apporte un gain en qualité du logiciel livré et en maintenance. Sous réserve que le surcout de l’automatisation reste inférieur au bénéfice apporté. Il importe pour chaque projet de définir une stratégie de tests, qui définit les approches retenues. L’objectif de cet article n’est pas de vous conseiller sur la stratégie de tests, mais plutôt de montrer qu’il est important de bien définir le vocabulaire, en tenant compte des champs sémantiques larges des termes utilisés.

Dans tous les cas, il me semble important de faire la distinction entre test unitaire et test automatisé. Le test unitaire peut être manuel, et le test automatisé peut très bien s’appliquer à des tests fonctionnels ou d’intégration. J’ai souvent entendu la mention de test unitaire pour en fait désigner des tests automatisés.

J’espère que ces quelques lignes permettront d’eviter de longues querelles d’experts qui disent peu ou prou la même chose sans sans rendre compte pour une simple raison de vocabulaire !

  1. Pas encore de commentaire
  1. Pas encore de trackbacks


cinq + = 10