Introduction
Lorsque l’on aborde le sujet des niveaux de test on cherche des exemples pour chaque niveau. Il est possible de faire une analogie mais, dans le cas contraire, on (moi compris) est souvent amené à dire que les tests composants peuvent être assimilés dans la plupart des cas aux tests unitaires.
A noter: cette confusion est également présente sur Wikipédia!
Pourquoi cette confusion ?
Les « testeurs » sont rarement amenés à travailler sur les tests de composants. En effet, les tests composants ont pour objectif de tester chaque « brique » qui compose le logiciel… et dans de nombreux cas ces briques se confondent avec les fonctions et le code écrit par les développeurs.
Les développeurs utilisant les tests unitaires pour tester leur code on fait le raccourci impliquant que les tests de composants sont les tests unitaires… ce qui, dans certains cas, comme nous allons le voir, peut s’avérer totalement faux.
Quelle différence entre ces termes ?
Tests unitaires
Concrètement les tests unitaires, sont des tests, généralement écrits par les développeurs (mais les développeurs ne font pas forcément du test unitaire!). Ces tests ont pour but de vérifier rapidement le bon fonctionnement d’une partie spécifique du logiciel, au niveau « atomique », c’est à dire du code.
Ces tests sont généralement FIRST, c’est à dire:
- Foudroyant (rapide) : S’exécute rapidement et est donc automatisé
- Isolé : Est indépendant des facteurs externes et des autres tests
- Répétable : Isole les bugs automatiquement
- Souverain (autonome) : N’est pas ambiguë (pas sujet à interprétation, ne demande pas une action manuelle pour vérifier le résultat)
- Tôt : Écrit en même temps que le code (même avant en TDD)
Les tests unitaires sont donc intrinsèquement liés au code.
Tests de composants
Les tests de composants, quand à eux représentent une « notion », un « niveau de test ». Le niveau test de composant représente le test des briques de notre logiciel. Dans le cas d’un logiciel simple on pense aux code, néanmoins cela peut couvrir beaucoup plus. De plus nous parlons ici d’un système « simple ». Il est facile d’imaginer (la taverne a d’ailleurs proposer un REX à ce sujet) un système plus complexe fait de plusieurs logiciels. Les composants de notre système sont alors des logiciels pris séparément. Chacun de ses logiciels ayant eux même leur propre niveaux de test.
On a alors:
- des tests de composants du système global qui se en fait les tests des différents logiciels (on pourrait les rapprocher des tests d’acceptation de ces logiciels). Ces tests sont loin de vérifier le code.
- des tests de composants de nos composants, qui là se base sur le code de nos logiciels composants
Conclusion
La confusion entre tests de composants et tests unitaires est un rapprochement bien pratique. Néanmoins il faut garder en tête que ce rapprochement, cette simplification peut mener à des confusion et des erreurs dans certains contextes. Je vous ai montré une grosse différence par rapport à la notion de niveau de test car je suis testeur, un développeur expérimenté trouverait des exemples aussi marquant sur les tests unitaires.
Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
N’hésitez pas à faire vos propres retours d’expérience en commentaire.
2 Responses
Bonjour Marc,
Dans le syllabus Fondation de l’ISTQB, on peut lire : « Component testing (also known as unit or module testing) focuses on components that are separately testable. » (page 31). Le reste du paragraphe 2.2.1 va aussi dans le sens que ce sont deux synonymes : même sujet de test (composant, unité, module, classe, selon les paradigmes de programmation des langages), isolation, mock, stub, proximité du code, etc.
Le terme de composant est seulement plus générique que celui de classe, dans la mesure où il faut un langage orienté objet pour créer une classe ou un paquetage (groupe de classes).
Je ne pense pas que le terme de composant puisse servir à désigner un logiciel déployable, on parle toujours des « composants d’un logiciel ».
Par ailleurs, on trouve la notion d’échelle mais dans les tests d’intégration : test d’intégration à petite échelle (aussi appelé test d’intégration de composants) et test d’intégration système.
Je pense avoir fait le tour du sujet quand j’ai dressé l’arborescence typologique des tests (https://gearsoftesting.org/test-typology.html), et pour avoir consulté de nombreuses sources alors, je n’ai plus de doute sur le fait que « test unitaire » et « test de composant » sont seulement des synonymes. Ce ne sont d’ailleurs pas les seuls : les synonymes sont très nombreux pour toutes les différentes formes de test connues. Il peut être parfois intéressant d’exploiter la présence de synonymes pour distinguer des formes de test d’après des critères précis. Toutefois, s’agissant des tests unitaires et des tests de composant, je ne vois pas de subtilité à valoriser.
Cordialement
Bonjour Xavier,
et merci pour ce retour.
J’avais exactement la même vision que toi pendant un long moment.
Néanmoins, cette vision a commencé à évoluer avec le passage de la certification Test Manager. On y voit clairement que les niveaux de test peuvent être adaptés avec, par exemple, l’ajout de niveaux. Le niveaux de test restent donc des concept et par conséquent plus abstrait que les tests unitaires.
Ma vision a continuer à évoluer avec mon travail sur la clé virtuelle. Dans mon cas mon « retravail » des niveaux de test c’est fait sous la forme de « poupées russes ». J’avais des logiciels (chacun avec ses niveaux de tests qui étaient eux-même des composant de mon système/produit clé virtuelle.
Les tests composant de mon produit clé virtuelle pouvait difficilement être considéré comme des tests unitaires.
Enfin, ce qui a finit de forger mon opinion c’est bien l’analyse des autres niveaux de test. Pour chaque niveau on spécifie bien qu’il peut y avoir plusieurs types de test (et ce quelque soit le type), que l’on ne peut les réduire à simplement un type de test. Ce que l’on fait habituellement avec le niveau composant est exactement ce que l’on nous dit de ne pas faire pour les autres… Ce qui crée, de mon point de vue, une grosse contradiction.
Je souhaite néanmoins rappeler que oui, dans une très grande majorité des cas, les tests de composants peuvent être considérés comme les tests unitaires (je pense que c’est d’ailleurs pour cela que c’est présenté comme tel dans le syllabus fondation de l’ISTQB)