Langage Ubiquitaire

Description

La notion de "langage ubiquitaire" est le même langage que l'on retrouve partout. Il est présenté dans la description du "Domain Driven Design" [Vernon 2016] [Moustier 2020]. Il correspond au même langage qui est partagé par tous les acteurs d'un même contexte au niveau :

• de l'entreprise
• de la technique
• des tests

‍

‍

Cette unité dans les termes et les expressions permet la communication entre tous les acteurs du contexte, un peu comme les habitants d'un même pays appelés "contexte délimité" dans le jargon DDD.

Ainsi, ce langage spécifique au domaine (DSL).

Application à la maturité des tests

Le langage omniprésent permet l'unité et la communication entre le côté commercial et le côté technique, ce qui rapproche encore plus le côté technique du côté commercial.

De plus, lorsque les tests sont cohérents avec le langage omniprésent, tout le monde peut les comprendre et participer à l'implication de tous dans la qualité du produit.

Une application directe du langage omniprésent est le développement guidé par le comportement (BDD), que l'on retrouve dans la description des histoires d'utilisateurs (US) et des critères d'acceptation correspondants :

● US:

        ○ En tant que client

        ○ J'ai besoin de pouvoir remplir mon panier d'achat,

       ○ POUR faire des achats.

● Scénario 1 :

        ○ DONNÉ que le client est "Albert",

        ○ QUAND "Albert" ajoute l'article "Carambar" au panier,

        ○ ET la "quantité" est "3"

        ○ ALORS le panier contient "3" "Carambar".

● Scénario 2 :

        ○ DONNÉ que le client est "Albert",

        ○ QUAND "Albert" ajoute l'article "Carambar" au panier,

        ○ ET la "quantité" est "3"

        ○ ET "4" "Carambar" sont supprimés de la carte,

        ○ ALORS, le message d'erreur "Vous ne pouvez pas supprimer plus de 3 Carambars" s'affiche.

        ○ ET le panier est vide.

Les expressions telles que le langage Gherkin [Wynne 2012] et les actions et les termes métier utilisés dans cet exemple doivent pouvoir être retrouvées dans les US, les tests (qui peuvent être interprétés par l'outil Cucumber) mais aussi dans l'architecture et le code afin de faciliter :

• la compréhension de la nécessité
• la reconnaissance des pièces techniques
• le but du test
  

par tous les acteurs du terrain et faciliter ainsi l'état d'esprit "T-Shape".

La position d'Agilitest sur cette pratique

Afin de refléter le DSL dans les scripts de test, les scénarios peuvent être décomposés selon les expressions du domaine. Ainsi, lorsque le langage Gherkin est utilisé pour matérialiser le BDD, il est de bonne pratique de diviser le scénario de test en créant des blocs GIVEN, WHEN et THEN comme le fait le compilateur Cucumber, en créant trois fonctions nommées d'après le texte suivant les mots-clés GIVEN/WHEN/THEN. Ainsi, en se basant sur l'exemple du scénario 1 présenté ci-dessus, on pourrait créer trois sous-scripts nommés :

• le_client_est_Albert
• Albert_ajoute_l'article_Carambar_au_panier_et_que_la_quantité_est_3
• le_panier_contient_3_Carambar

‍

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

‍