Harnais de tests

Description

Dans l'industrie du câble, les fils sont posés sur un banc qui reproduit la disposition finale de l'intégration. Les câbles sont harnachés sur une planche avec des points de fixation prédéfinis qui correspondent aux emplacements réels de fixation. Cette façon de travailler est appelée "harnachement des câbles", certainement parce que les câbles générés ressemblent à des harnais à mettre sur un cheval.

‍

Selon l'ISTQB, un harnais de test (TH) est "un environnement de test composé de stubs et de drivers nécessaires à l'exécution d'un test" [ISTQB 2015]. Les pilotes, associés à des moyens de test automatisés, suivent un scénario de test et injectent des données dans un composant sous test (CUT) et les stubs (alias "doubles de test" - TD) simulent les composants dont dépend le CUT. Ces TD sont utilisés pour isoler le CUT des comportements externes et incontrôlés [Ribeiro Rocha 2008]. Dans notre exemple de harnais de câbles, l'ensemble de la carte du harnais agit comme un Stub de l'environnement d'exploitation et les waypoints à bord fourniront des pilotes répétables et isolés pour garantir que les câbles produits s'adapteront à l'environnement d'exploitation.

‍

Le TH : 

• fait partie des éléments livrables d'un projet, mais est généralement séparé du code source de production 
• est partagé et réutilisé sur plusieurs projets.

Un TH permet notamment la :

• Simulation de cas particuliers et de situations difficiles à configurer dans un environnement de type production.
• Augmentation de la probabilité que les tests de régression aient lieu parce que les TH exploitent les cas de coin.
• Des scripts de test plus rapides, puisque les stubs sont inévitablement plus rapides que les composants qu'ils simulent, surtout lorsque les parties simulées sont sur le réseau.
• Répétabilité des essais ultérieurs car TH empêche toute variation des données provenant des pièces simulées, et donc les faux positifs.
• Tests hors ligne car les parties distantes, telles que les services web, sont simulées localement.
• Détection des caractéristiques manquantes entre la CUT et l'intention de test [André 2013].
• Testabilité puisque TH génère des Drivers et TD, alors des interfaces sont nécessaires sur le CUT pour le piloter
• Amélioration de la modularité [Gao 2003]
• Test d'intégration avec des éléments fictifs et évite les approches de type "big bang".

‍

En matière de TD, les développeurs ont créé quelques termes pour présenter différentes capacités, avec des différences subtiles entre ces définitions [Meszaros 2011] [Sheel 2021] et des similitudes déroutantes :

• Stubs: TD avec des valeurs codées en dur pour les appels de méthode - ils renvoient toujours le même résultat, quelle que soit l'entrée.
• Mocks: amélioration des stubs avec des réponses dynamiques basées sur des scénarios
• Fakes: mise en œuvre concrète qui fonctionne comme la mise en œuvre réelle avec une version simplifiée du code de production sans dépendances lourdes.
• Les espions: ce type de TD permet de savoir quand les fonctions ont été appelées, avec quels arguments...

Ces termes donnent une idée de l'utilisation étendue des TD ; ils pourraient également inclure les simulateurs avec des caractéristiques contrôlables comme une extension des Fakes. Les simulateurs ne sont pas seulement des cockpits semblables à des avions sophistiqués, mais aussi tout TD qui simulerait un backend pour éviter les conséquences dramatiques d'un CUT mal codé. Cela se produit avec tout dispositif ou actif qui serait soit coûteux, soit rare, soit trop lent, soit doté de caractéristiques incontrôlables/inexistantes dans la vie réelle. Par conséquent, dans la plupart des domaines matures tels que l'assurance [DOCOsoft 2015], la bourse [Kriger 2015] ou le transport [BugRaptors 2019], des solutions et des services prêts à l'emploi ou des certifications existent pour tester les CUT par rapport à une plateforme ou une norme.
La TH pour les grands logiciels se traduit généralement par le provisionnement de ces TD dans un cadre composé d'outils et de méthodes. Le cadre est mis à disposition pour résoudre les problèmes d'interopérabilité B2B [Jardim-Gonçalves 2007] avec des stubs générés dynamiquement [Ribeiro Rocha 2008]. 

Les simulateurs, comme tout TD, ont pour but d'apprendre quelque chose sur le CUT. Les simulateurs d'avions visent à tester le pilote et à informer les auditeurs de la courbe d'apprentissage de celui qui apprend principalement, le pilote.

Impact sur la maturité des tests

Le TH peut être conçu dans un processus de test basé sur un modèle (MBT) [Ribeiro Rocha 2008] :

1. partir du diagramme de séquence ou des diagrammes d'activité ou de toute représentation de séquences d'exécution d'opérations 
2. convertir le diagramme en un graphe de séquence
3. sélectionner des chemins dans ce graphe pour concevoir des cas de test
4. spécifier les cas de test correspondant à chaque chemin sélectionné
5. identifier les entrées de données nécessaires pour que chaque chemin de scénario soit emprunté
6. implémenter les cas de test dans le langage de programmation de son choix

Dans une approche basée sur les modèles, les TH peuvent également être générés dans une approche de conception dirigée par les modèles (MDD) [André 2013] :

‍

‍

Même si une telle méthode de travail peut être facilement comprise par les gestionnaires, il semble que le DDM présente certains pièges [Den Haan 2009] :

• Le DDM introduit en fait beaucoup de rigidité 

• Les modèles sont flexibles si seul l'outil de détection de mines est utilisé.
• Les rôles des membres du projet sont très différents, avec une "Meta-Team" qui construit l'usine logicielle pilotée par le modèle, ce qui génère une certaine distance entre les développeurs et l'entreprise.
• L'outil/approche de modélisation est "presque" terminé au début du projet - le silo généré par la Meta-Team produit généralement un modèle qui ne peut pas être testé à 100%, ce qui peut générer d'énormes impacts lorsqu'il s'agit de grands projets.
• À partir du modèle, l'équipe chargée des exigences n'est pas en mesure de comprendre ce qui est autorisé et ce qui ne l'est pas, ce qui introduit des hypothèses erronées.
• La MDD requiert de l'expérience
• Les gens ont tendance à se concentrer sur le nouvel outil qu'ils utilisent et sur toutes ses fonctionnalités, ce qui les éloigne de la réalité commerciale et technique.

Pour atténuer cet effet de cascade, il faut commencer à tout faire en même temps, notamment avec des outils tels que Swagger ou Postman [Clayton 2022]. Ces plateformes permettent de générer la :

• Spécification de l'API pour générer des TD et des Drivers
• Documentation de l'API

virtuellement à partir d'une seule entrée.

Le développement piloté par les tests (TDD) peut être une bonne occasion de gérer le TH. Le TDD existe en deux "écoles" :

• École de Détroit: l'approche TDD classique basée sur une approche ascendante et approfondie [Beck 2002] [Henke 2018].
• L'école de Londres: une approche descendante [Freeman 2009].

Pour les deux écoles, les dépendances des composants sont gérées avec la TD, et les tests sont exécutés une fois que les composants peuvent être déployés [Heineman 2009].

Dans le cadre du CI/CD, les tests d'intégration sont parfois tout simplement ignorés grâce au TH. Les problèmes d'intégration sont en fait expérimentés par certains utilisateurs (par exemple, Canary Releasing ou Crowd Testing) pour s'attaquer aux cas de coin dans une approche stochastique.

Dans les systèmes critiques, les composants sont dotés de fonctions d'autotest pour permettre un diagnostic dans des conditions de fonctionnement grâce à l'autotestabilité intégrée (BIST) [Agrawal 2003]. Cette stratégie peut être utilisée pour les composants déployés et partagés avec différentes tierces parties qui ont besoin de robustesse pour supporter des utilisations inconnues [Mariani 2004]. Cette approche Shift Right est basée sur un mode de test isolé. Pour l'activer, un signal ou une commande est envoyé(e) aux composants BIST ciblés pour qu'ils passent en mode autotest [Agrawal 2003]. Cela signifie que les TH font également partie du code de production, d'où une approche "Design for Testability and Built-In Self-Test" (conception pour la testabilité et l'autotest intégré) qui existe sous plusieurs formes bien connues des fabricants de matériel [Ben Jone 2022].
Une adaptation possible du BIST aux solutions logicielles pourrait être un dispositif de test, par exemple une ressource API REST spéciale. Cette ressource positionnerait le bien en mode maintenance et bloquerait ensuite les appels réels avec certains TD pendant l'exécution des autotests. 

Enfin, les TDs peuvent également être enrichis à partir des données de production pour améliorer les autotests à la manière de Jidoka .

Le point de vue d'Agilitest sur cette pratique

Agilitest est clairement un Driver. L'outil d'automatisation permet de piloter des applications web, MS Windows, mobiles et des services web.

La plupart des clients d'Agilitest sont orientés business grâce au scripting #nocode. La création de TD requiert généralement quelques compétences techniques, ce qui implique des relations étroites entre les "testeurs fonctionnels" et les développeurs, la partie sociale de la testabilité.

‍

Pour découvrir l'ensemble des pratiques, cliquez ici.

‍