Comment et pourquoi adopter le BDD dans le développement de logiciels

Le développement axé sur le comportement (BDD) résout le problème de la mise en œuvre d'exigences mal définies en tirant parti de l'expertise du domaine des professionnels de l'entreprise et de l'assurance qualité pour s'assurer que l'équipe de développement crée le bon logiciel. Lisez la suite pour en savoir plus sur l'adoption de BDD dans l'entreprise.

Au cours des dernières années, de nombreuses organisations sont passées à Développement agile afin d'accélérer la livraison et d'obtenir des retours plus rapides du marché. Dans ces organisations, alors que le développement commence à aller plus vite, l'assurance qualité aura du mal à suivre le rythme à moins qu'elles n'intègrent des pratiques de test logiciel automatisé dans le pipeline de développement, ce qui est souvent le premier goulot d'étranglement à surmonter.

Mais après l'adoption réussie de l'automatisation des tests et une évolution plus rapide de l'ensemble de l'organisation, les organisations commencent à se demander si elles construisent le droit Logiciel. Accélérer le développement de logiciels et assurer la qualité des logiciels avec tests continus automatisés est une grande réussite, mais cela ne sert à rien si le logiciel n'est pas ce que vos clients veulent ou dont ils ont besoin.

Les personnes à ce stade de l'évolution de leurs processus de développement de logiciels examinent de près BDD comme un moyen de s'assurer que leurs logiciels répondent aux exigences commerciales de leur organisation. Mais qu'est-ce que BDD exactement et comment se rapporte-t-il aux tests?

TDD contre BDD

BDD est une évolution du méthodologie de développement piloté par les tests (TDD), dans lequel les développeurs écrivent le test Eux avant nous écrire le code. Après avoir conçu un test qui a échoué pour démarrer, les développeurs pratiquant le TDD écrivent juste assez de code pour s'assurer que le test réussit, puis écrivent un autre test; rincer et répéter. Le résultat est un code léger et moyen avec une couverture de test élevée.

TDD est une activité conçue pour améliorer la qualité des logiciels et assurer la couverture du code. BDD, en revanche, résout le problème de la mise en œuvre correcte des exigences. Plutôt que de se concentrer sur le tester pour vérifier le   vous voulez implémenter, BDD consiste à définir le humain de l'application afin qu'elle réponde à une activité spécifique exigences.

La similitude entre TDD et BDD est qu'un mécanisme contractuel est mis en œuvre avant tout travail, pour s'assurer que la sortie correspond à une attente spécifique. Mais c'est là que s'arrête la similitude. Dans TDD, le test est un contrat destiné à garantir que l'application répond à une exigence fonctionnelle spécifique. Dans BDD, le comportement est le contrat destiné à garantir que l'application répond à une exigence métier spécifique.

Qu'est-ce que BDD dans le développement de logiciels?

Nous avons jeté avec désinvolture le terme «comportement», mais il a un sens technique dans le contexte de BDD. Dans BDD, comportements sont des déclarations soigneusement conçues et lisibles par l'homme qui suivent un format spécifique. Ils sont rassemblés dans des «fichiers de fonctionnalités» qui peuvent être intégrés dans le processus de développement.

Les fichiers d'entités sont généralement écrits en Gherkin, qui est une syntaxe spécifique à BDD qui permet aux outils BDD, tels que Cucumber et SpecFlow, d'automatiser le processus de validation des comportements. Ces outils BDD analysent les comportements dans le fichier d'entités et exécutent le «code de collage» approprié. Ce code glue mappe les «comportements» aux étapes d'exécution, généralement du code de test Java ou .NET écrit par un développeur, dans un moteur de test spécifique. Ces mappages sont communément appelés «définitions d'étape» ou «définition d'étape». Par conséquent, les testeurs peuvent utiliser des fichiers de fonctionnalités comme cas de test qui vérifient les comportements associés aux exigences.

Quels sont les avantages de BDD?

Le développement axé sur les affaires apporte plusieurs avantages au développement de logiciels. Avec BDD, vous pouvez:

• Augmentez la collaboration. BDD fournit un langage commun pour les différents rôles dans l'organisation. Cela aide les membres de l'équipe technique et non technique à comprendre les fonctionnalités prévues et les exigences commerciales du projet.
• Tirez parti d'un plus large éventail d'expertises dans le domaine. Étant donné que les comportements sont définis dans un format compréhensible par l'homme, les organisations peuvent tirer parti de l'expertise des testeurs, des architectes et d'autres parties prenantes qui ont des perspectives et des antécédents différents.
• Répondre aux exigences en mettant l'accent sur les tests. BDD pilote la couverture des tests en mettant l'accent sur la satisfaction des exigences, ce qui garantit que le produit final est pertinent par rapport aux besoins commerciaux d'une organisation.
• Favorisez la réutilisation et réduisez la complexité de l'automatisation. Les développeurs qui écrivent le code glue sont encouragés à écrire réutilisable étapes de test, ainsi que du code plus testable. Par exemple, une application peut avoir des étapes de configuration répétitives qui doivent être appelées pour atteindre un certain état. Un développeur peut définir ces étapes dans le code de collage, qui peuvent être réutilisées pour gérer la configuration et l'exécution.

Ce dernier point est l'une des principales caractéristiques de BDD. Des étapes de test modulaires et réutilisables permettent aux testeurs de s'appuyer sur l'outil BDD pour effectuer le gros du travail lors de la vérification et de la validation des exigences. Le point de friction, cependant, est que les développeurs sont toujours tenus d'écrire le code de glue qui lie les comportements aux exigences. Nous en reparlerons plus en détail ensuite.

Coûts de mise en œuvre de BDD dans l'entreprise

Le plus gros coût associé à la mise en œuvre de BDD est l'écriture du code glue. Dans la plupart des cas, cette tâche incombe à l'équipe de développement, ce qui déplace le fardeau de la création des artefacts de test pour valider les exigences des testeurs aux développeurs.

Dans un monde pré-BDD, les testeurs utiliseraient des outils et des frameworks pour créer des tests qui valident la fonctionnalité, pas nécessairement les exigences. Avec BDD, les testeurs, les analystes commerciaux et d'autres parties prenantes définissent les comportements dans un fichier de fonctionnalités, mais les développeurs ou les personnes ayant des compétences en écriture de code sont toujours tenus d'écrire le code glue qui mappe les comportements à la fonctionnalité.

Le fait que BDD augmente le coût du développement peut nuire aux organisations dont les ressources de développement sont limitées. Bien que le code glue soit destiné à être réutilisable et plus facile à exploiter pour l'automatisation des tests, l'investissement requis pour faire évoluer et mettre en œuvre BDD dans toute l'entreprise est souvent trop élevé.

Comment réduire la charge technique du BDD

Parasoft aide à réduire la charge technique associée à la création et à la maintenance du code de test BDD. Il existe plusieurs approches pour les tests automatisés d'une application, principalement les tests d'API et les tests d'interface utilisateur. Parasoft peut réduire la charge technique de chacun de différentes manières;

Réduisez les obstacles techniques à la mise en œuvre du code de test via des tests API avec BDD

Parasoft permet aux non-développeurs d'écrire des step-defs qui s'exécutent en tant que tests SOAtest, ce qui réduit considérablement les ressources techniques nécessaires pour écrire des tests. Avec Parasoft SOAtest-Cucumber Executor, chaque définition d'étape correspond à un test SOAtest réutilisable ou à une suite de tests qui s'exécute lorsque cette étape est exécutée.

Considérez les exemples suivants:

• Une définition d'étape fait référence à un client SOAtest REST qui appelle une API spécifique
• Une deuxième étape de définition fait référence à un client SOAtest REST connecté à un asserteur JSON qui valide les données dans une réponse d'une API différente
• Une troisième étape de définition fait référence à un outil de base de données SOAtest connecté à un asserteur de valeur qui exécute une requête de base de données et valide les données dans le jeu de résultats.

Les définitions d'étape peuvent également faire référence à un test SOAtest individuel ou à une suite de tests contenant un certain nombre de tests.

Réduisez les coûts de maintenance continus de l'automatisation des tests d'interface utilisateur avec Selenium et BDD

Des défis techniques supplémentaires et uniques surviennent lors de l'intégration des tests d'interface utilisateur dans votre solution BDD. Semblable à La solution de test d'API de Parasoft, Parasoft Selenic a la capacité d'enregistrer des actions d'interface utilisateur à partir du navigateur et de créer du code Selenium pur qui peut être associé à vos définitions d'étape pour piloter l'automatisation des tests d'interface utilisateur. Pour réduire la maintenance continue des scripts Selenium purs, Parasoft Selenic crée des tests Selenium en exploitant le modèle d'objet de page. Le modèle d'objet de page est un paradigme de conception de test d'interface utilisateur dans lequel les utilisateurs peuvent définir des éléments d'interface utilisateur en association avec les pages sur lesquelles ils sont présents. Cela facilite grandement la maintenance de vos scripts car les emplacements des éléments sont définis en un seul endroit, puis exploités. dans votre suite de tests. En plus de réduire les compétences techniques requises pour créer les scripts de test initiaux en premier lieu.

Cependant, la création est un coût ponctuel et la majorité de la charge engendrée par le code de test BDD est en maintenance. Au fil du temps, à mesure que votre application change, les localisateurs d'éléments et les conditions d'attente initialement définis dans le code de test Selenium sous-jacent peuvent se rompre. Cela crée de la confusion lors de l'examen des résultats des tests, car il est difficile de déterminer si vos tests échouent en raison de réels défauts dans l'application ou de simples modifications de l'interface utilisateur. Cela érode la valeur fournie par BDD. 

Activé dans votre IDE, ou, pour CI / CD, avec un changement de code d'une ligne à votre exécution de ligne de commande, Parasoft Selenic effectue une analyse d'exécution de l'exécution du test. Lorsqu'un test échoue, il applique ses heuristiques d'intelligence artificielle pour déterminer comment cet échec aurait pu être évité, par exemple en mettant à jour les localisateurs ou les conditions d'attente), puis tente de auto-réparer le test au moment de l'exécution afin que le pipeline puisse continuer. Vous évitez de gaspiller des cycles de débogage des échecs de construction dus à des tests instables, et il en apprend plus sur vos tests en même temps.  

Tout cela réduit le temps que vous consacrez à la maintenance, à la réparation et à la correction des tests interrompus et vous permet de profiter des véritables avantages de BDD, à savoir une collaboration accrue et une confiance accrue grâce à l'automatisation des tests.

Réduisez les coûts associés à l'automatisation des tests et au BDD

Parasoft donne plus de contrôle aux testeurs et leur donne l'assurance qu'ils ont complètement couvert la fonctionnalité testée. Tirer parti d'un solution de test mature, riche en fonctionnalités et de bout en bout permet une entrée facile dans l'automatisation des tests, la maintenance des tests et une intégration naturelle dans les flux de travail CI / CD existants. À un niveau élevé, il permet aux organisations de tirer parti de moins de ressources techniques pour mettre en œuvre BDD, en libérant des ressources de développement, en modifiant la zone de création comme illustré ci-dessous:

Conclusion

BDD est une pratique de développement puissante qui peut garantir que la fonctionnalité correcte est en cours de construction. Cependant, la mise à l'échelle de BDD au niveau de l'entreprise peut être difficile car la mise en œuvre de la pratique nécessite un large pool de ressources techniques. Parasoft abaisse la barrière technique en permettant aux utilisateurs de mapper les déclarations de comportement aux définitions d'exécution des étapes à l'aide d'un interface utilisateur simple à comprendre. Les définitions d'étape sont exécutées comme SOAtest tests, ce qui facilite grandement la tâche des testeurs et du personnel non technique à contribuer au processus de vérification. Parasoft Sélénic réduit la maintenance continue associée aux tests d'interface utilisateur via Selenic en fournissant des recommandations générées par l'IA pour les localisateurs et les conditions d'attente au moment de l'exécution.  

Contactez-nous si vous souhaitez en savoir plus sur le Parasoft SOAtest-Exécuteur de concombre. Ou demandez un essai gratuit en cliquant ci-dessous. 

Par Grigori Trofimov

Grigori Trofimov est un architecte de solutions chez Parasoft, fournissant des services de conseil pour les solutions de test de Parasoft aux prospects, clients et partenaires. Il a récemment pris la parole lors de conférences sur le thème de la virtualisation des services et du déploiement d'environnements jetables dans le cloud.