ATDD

Description

ATDD est l'acronyme de "Acceptance Test-Driven Development". ATDD trouve ses racines dans la pratique du TDD. L'idée de l'ATDD semble émerger avec Lisa Crispin [Crispin 2000] qui suggère déjà d'automatiser les tests d'acceptation (AT) écrits avant le code [Kaner 2002].

ATDD consiste en [Axelrod 2018] :

1. définir le site ATs pour chaque nouvelle histoire d'utilisateur (US)
2. une mise en œuvre du site ATs avec du code de production
3. un code de production minimal qui est généré pour passer le ATs avec le Definition of Done (DoD)
4. lorsque tous les ATs passent, les USpasse ; c'est "fait" si la DoD passe aussi [Schwaber 2020].

ATDD n'est pas seulement pour les interfaces graphiques mais pour tout type d'interface les UScomme les API REST, les RPC ou d'autres mécanismes permettant d'assurer la testabilité du carnet de commandes.

ATs peut [Axelrod 2018] :

• aider l'organisation à se concentrer sur le client en améliorant la communication entre le propriétaire de l'entreprise et l'équipe de développement
• aider l'équipe de développement à comprendre les progrès et les éléments à tester 
• aider les clients et les équipes de développement à s'assurer que le projet progresse dans la bonne direction [Crispin 2000] [Deng 2009]
• forcer pour commencer à planifier un code de production testable
• garantir que les testeurs et les scripteurs sont impliqués le plus tôt possible, ce qui leur permet d'influencer réellement la qualité du produit
• être utilisé comme un test de régression et permet une exécution automatique sur une base régulière et permet au code d'être remanié en toute sécurité
• améliorer la précision de l'estimation de l'effort de développement si ATs est écrit à l'avance (par exemple, au cours d'une session 3 Amigos ou d'une session de cartographie des exemples au moment du raffinement du sprint).
• être utilisé comme documentation à la "manière Agile" et fournir des "spécifications exécutables" [Ambler 2005]
• être exécuté juste après la ligne de code la plus simple censée mettre en œuvre l'AT au lieu d'attendre une version candidate de la solution complète, conformément au principe de test "Shift Left"
• être répété à un rythme plus élevé s'il est répété, plutôt qu'à la fin du SDLC, réduisant ainsi les risques de non-conformité très rapidement.

Les ATDD sont des spécifications exécutables, ce qui signifie que les ATDD sont comme une "Bande de Möbius" : les deux côtés de l'AT sont en fait les mêmes ; l'automatisation du script de test les rend exécutables [Moustier 2020].

‍

‍

Pourquoi avons-nous besoin de l'automatisation des tests ?

‍

1. l'automatisation réduit les " coûts de transaction " [SAFe 2021-06] : dans le modèle de livraison itératif, chaque fois qu'un lot de livraison doit être déployé, il supporte certains coûts qui doivent être maintenus bas pour permettre des mises en production fréquentes. 
2. de faibles coûts de transaction réduisent également le coût de détention [SAFe 2021-06] : le fait de retarder la mise sur le marché entraîne un manque à gagner pour les clients et les concurrents peuvent tirer profit de la valeur ajoutée non livrée.
3. l'automatisation permet de réaliser des tests rapides, entièrement répétables et précis [Axelrod 2018].
4. il aide à effectuer des tests de régression sans aucune connaissance du produit
5. Agile, et plus généralement DevOps, reposent sur une stratégie d'automatisationpoussée.

‍

"L'automatisation des tests" présente bien sûr des inconvénients tels que :

• scripts maintenance pour s'adapter aux modifications des interfaces telles que l'IU ou l'API
• les données d'essai doivent être maintenues/migrées pour correspondre aux changements d'activité et à leur mise en œuvre
• les faux positifs (aka "Flaky tests") doivent être chassés dans une approche Jidoka
• un script n'est pas un test et s'appuyer uniquement sur des cas de test scriptés n'est pas suffisant [Bach 2014]
• si l'automatisation des tests se fait en mode silo, des goulots d'étranglement apparaîtront
• les tests automatisés doivent démarrer à partir d'un état initial bien connu, car un échec dans le scénario interrompt le test et saute au suivant ; par conséquent, l'échec d'un test ne doit pas affecter les tests suivants et les dépendances entre les tests automatisés sont fortement déconseillées [Axelrod 2018].

L'ATDD est souvent confondu avec le développement piloté par le comportement (BDD). Le BDD est une méthodologie qui vise à combler l'écart entre la description d'un comportement et sa mise en œuvre. Le comportement est décrit en langage naturel et remplace les spécifications formelles. Il est accompagné de tests qui vérifient la fonctionnalité [North 2006] [Axelrod 2018] [Moustier 2019-1].

Alors que BDD est axé sur les comportements du point de vue du client, ATDD vise à tester les critères d'acceptation. D'une part, BDD décrit l'activité (outside-in) et fournit des critères grâce à ce que l'on appelle les "spécifications par exemples" (SBE) [Fowler 2004] ; d'autre part, ATDD permet le côté technique de l'AC, il fait la transition de l'outside-in à l'inside-out pour TDD [Moe 2019].

Parallèlement à BDD, créé par Dan North [North 2006], est apparu un outil appelé "Cucumber" [Wynne 2012] [Ye 2013] qui compile une spécification de comportement en langage naturel formaté en stubs de code prêts à intégrer l'implémentation du test. Le BDD permet donc l'ATDD [Axelrod 2018].

Ce "langage naturel" utilisé par Cucumber a été surnommé "Gherkin". Voici la structure de ce langage naturel :

Feature: <US name>

    As a <User Type>

    I need to <do something>

    So that <benefit of the action>

Scenario X : <scenario test name X>

    Given <context X>

    When <something happens>

    Then <items to check with AND, THEN or BUT between items>

‍

La quantité de scénarios peut varier d'un US à l'autre ; en fournir trop pour le même US n'est pas une bonne pratique car cela génèrera un US qui serait trop grand pour être traité dans un Sprint.

‍

À partir de la description Gherkin, la plupart des frameworks BDD génèrent le squelette du code de test unitaire. Le squelette de test unitaire généré doit ensuite être rempli d'instructions et d'appels à définir [Axelrod 2018].

• la condition initiale - la partie "Given" (donnée).
• le produit à la situation attendue - la partie "Quand".
• les contrôles définis à effectuer - la partie "Ensuite".

Ces outils sont en fait basés sur des mots-clés qui reçoivent l'implémentation, tout comme l'approche Keyword-Driven Testing (KDT) où chaque partie du Gherkin est considérée comme un mot-clé [Deng 2009].

D'autres outils BDD vous permettent d'intégrer la documentation dans le code de test lui-même, par exemple :

• RSpec pour Ruby
• Spectre pour Java
• MSpec pour .Net
• Jasmine et Mocha pour JavaScript

Impact sur la maturité des tests

ATDD est fortement lié à TDD, en raison de son origine [Crispin 2000] mais aussi parce que ATDD renforce TDD en fournissant le squelette des tests unitaires qui doivent être remplis avec des appels au code de production. Cela génère un système d'apprentissage en double boucle [Argyris 1977] [Smith 2001] qui permet de fournir la bonne solution au lieu de la seule conformité aux tests unitaires.

ATDD et TDD sont un système d'apprentissage en double boucle [Ambler 2006].

‍

Ce système d'apprentissage en double boucle devrait également être inclus dans une boucle de niveau supérieur telle que le Lean Startup [Ries 2012]. Cela permettrait de livrer le bon produit au lieu de quelque chose qui serait simplement conforme à la définition US.

‍

Lean Startup comme mécanisme d'apprentissage en double boucle par rapport à la double boucle ATDD/TDD [Moustier 2020].

Ces systèmes à double boucle peuvent inclure des niveaux de boucle intermédiaires comme dans le cas de l'Extreme Programming [Beck 2004] qui fournit un retour d'information à plusieurs niveaux et à plusieurs fréquences [DonWells 2013].

L'Extreme Programming nécessite une planification et un retour d'information à plusieurs niveaux et à plusieurs fréquences [DonWells 2013].

L'ATDD étant basé sur le BDD, les non-programmeurs sont alors en mesure de créer des tests [Kaner 2002] et d'assurer une liaison transparente avec les travailleurs des niveaux inférieurs. Gherkin et SBE visent tous deux à fournir un moyen de communication qui combine les critères d'utilisation et d'acceptation entre l'AT et les tests unitaires, mais l'état d'esprit "Test First" peut être étendu aux systèmes connectés à double boucle mis en œuvre dans l'organisation. Dans le prisme de l'ATDD, les organisations sont de différentes saveurs :

• Équipe dédiée : responsabilité complète mais l'équipe de scripteurs sera déconnectée de l'équipe de développement. Cette configuration introduit des problèmes dans un contexte DevOps [Axelrod 2018] ; cela conduit à fusionner les scripteurs au sein des équipes de développement.
• Des scripteurs isolés au sein des équipes de développement créeraient des goulots d'étranglement au sein de l'équipe et renforceraient la loi de Conway [Conway 1968], augmentant ainsi les problèmes lors de l'intégration des pièces.
• Membres de l'équipe T-Shape : pour désengorger le goulot d'étranglement des tests, les développeurs contribuent aux tests en automatisant les scripts.
• Feature Teams une fois que les compétences ne sont plus une, l'ensemble de l'équipe peut gérer les tests E2E avec ATDD - généralement, un objectif commun, quelques mesures pertinentes pour surveiller le succès, et des valeurs communes aident l'équipe à dépasser le paradigme de l'équipe de fonctionnalité [North 2016].

‍

Un autre sujet que l'automatisation des tests attire est la gestion des données de test (TDM). 

Le TDM est un sujet majeur dans l'automatisation des tests. Les données peuvent être générées à partir des données de production par le biais de la BI et éventuellement grâce à l'IA [Legeard 2021]. Lorsqu'il s'agit de nouvelles fonctionnalités, les données de production manqueront probablement ; malheureusement, l'ATDD concerne principalement les nouvelles fonctionnalités, ce qui en fait un anti-modèle. En outre, le test guidé par les données est facile au niveau des unités de test [Axelrod 2018], mais lorsqu'il s'agit de systèmes complexes et de logiciels de test, cela peut être vraiment difficile en raison de la quantité de données à gérer. Pour aider cela, les données peuvent être organisées grâce à un dictionnaire où chaque cas de test possède ses propres données qui doivent être injectées (et éventuellement anonymisées ou obfusquées) dans l'environnement de test [Axelrod 2018].

A la fin du scénario, les données doivent également être réinitialisées pour permettre la répétition des tests. Si des tests menés en parallèle devaient toucher les mêmes données, plusieurs environnements doivent être mis à disposition [Axelrod 2018] notamment grâce à :

• la gestion des nuages ainsi qu'une approche en 12 facteurs ;
• des stratégies de stockage des données telles que le partage des données en lecture seule [Axelrod 2018], l'utilisation du mécanisme de réplication de la base de données [Wiesmann 2000] ou l'application d'une conception CQRS [Fowler 2011] ;
• lancement sombre pour acheminer les modifications de données vers des stockages spécifiques lorsqu'il s'agit d'isoler les modifications de test.

La GDT est quelque chose de complexe et de difficile à aborder ; c'est pourquoi elle doit être traitée petit à petit, à tout moment, dès le début.

Le point de vue d'Agilitest sur cette pratique

Parce qu'Agilitest est un outil de script #nocode, les développeurs ne font généralement pas confiance à la technologie ; par conséquent, de nombreux utilisateurs d'Agilitest sont des personnes orientées vers les affaires. Cette situation conduit souvent les gestionnaires à mettre en place une organisation orientée vers les silos afin de réaliser rapidement l'automatisation des tests dans leur entreprise. Cependant, cette réalisation n'est pas l'objectif réel. Comme nous l'avons montré ci-dessus, l'état d'esprit introduit par ATDD est essentiellement une question de communication ; la diffusion des outils qui permettent ATDD est vitale pour le flux de livraison. Le partage des préoccupations concernant les outils ATDD entre les développeurs et les scripteurs vise à fusionner les écocycles de développement et d'automatisation des tests. Cela passe notamment par 

• connecter Agilitest à un serveur Jenkins existant 
• l'extraction de données des bases de données pour tirer parti de la fonctionnalité Data-Driven d'Agilitest

‍

Enfin, l'automatisation des scripts de test infère des défaillances mineures qui peuvent bloquer l'exécution des parties plus importantes du test [Axelrod 2018] ; les tests doivent donc être courts. Certains des utilisateurs d'Agilitest possèdent des scripts avec beaucoup d'étapes : un script de 3000+ étapes a été enregistré ! La bonne nouvelle est que cela prouve que l'outil est robuste ; cependant, il est préférable de concevoir des scripts qui ne vérifient qu'une seule chose.

‍

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

‍