Comment adopter avec succès le développement de logiciels BDD et pourquoi c'est important

Introduction au développement de logiciels BDD

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 bon 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.

À ce stade de l'évolution de leurs processus de développement logiciel, les personnes examinent de près BDD comme moyen de garantir que leurs logiciels répondent à leurs attentes. les exigences commerciales de l'organisation. Mais qu’est-ce que le BDD exactement et quel est son rapport avec les tests ?

Comprendre BDD dans le contexte de BDD

BDD est une évolution du méthodologie de développement piloté par les tests (TDD), dans lequel les développeurs écrivent le test before écrire le code. Après avoir créé un test ayant échoué pour démarrer, les développeurs pratiquant le TDD écrivent juste assez de code pour garantir la réussite du test, puis écrivent un autre test. Rincer et répéter. Le résultat est un code simple et efficace 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 qui rend BDD unique 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 rédigées 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 au processus de développement.

Les fichiers de fonctionnalités sont généralement écrits en Gherkin, 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 de fonctionnalités et exécutent le « code de colle » approprié. Ce code de colle 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'étapes » ou « définitions d'étapes ». En conséquence, les testeurs peuvent utiliser des fichiers de fonctionnalités comme scénarios de test qui vérifient les comportements associés aux exigences.

Avantages de BDD dans le développement de logiciels

Le développement axé sur les entreprises présente plusieurs avantages pour le développement de logiciels. Avec BDD, vous pouvez :

• Augmentez la collaboration. BDD fournit un langage commun pour les différents rôles au sein de 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 gère la couverture des tests en mettant l'accent sur le respect 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 qu'un code plus testable. Par exemple, une application peut comporter des étapes de configuration répétitives qui doivent être invoquées pour atteindre un certain état. Un développeur peut définir ces étapes dans le code Glue, 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 validant la fonctionnalité, pas nécessairement les exigences. Avec BDD, les testeurs, les analystes commerciaux et 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 rédaction de code doivent toujours écrire le code de liaison 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é.

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 tester automatiquement une application. Parmi ceux-ci figurent principalement les tests d’API et les tests d’interface utilisateur. Parasoft peut réduire la charge technique de chacun des manières suivantes.

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 définitions d'étape qui s'exécutent en tant que tests SOAtest, ce qui réduit les ressources techniques nécessaires pour écrire des tests. Avec Parasoft SOAtest-Cucumber Executor, chaque définition d'étape correspond à un test SOAtest ou à une suite de tests réutilisable 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 définition d'étape fait référence à un client SOAtest REST connecté à un assertor JSON qui valide les données dans une réponse provenant d'une autre API.
• 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 les actions de l'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 de l'interface utilisateur.

Pour réduire la maintenance continue des scripts Selenium purs, Parasoft Selenic crée des tests Selenium exploitant le modèle objet de page. Le modèle 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 rend beaucoup plus facile 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 unique et la majorité de la charge liée au code de test BDD concerne la maintenance. Au fil du temps, à mesure que votre application modifie les localisateurs d'éléments et les conditions d'attente initialement définies dans le code de test Selenium sous-jacent peuvent être rompues. 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 défauts réels 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 une modification de code sur une ligne dans votre exécution en 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'IA 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 défectueux et vous permet de profiter des véritables avantages du 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 entre les mains des testeurs et leur donne l'assurance qu'ils ont complètement couvert la fonctionnalité testée. L’exploitation d’une solution de test de bout en bout mature et riche en fonctionnalités permet un accès facile à l’automatisation des tests, à la maintenance des tests et à une intégration naturelle dans les flux de travail CI/CD existants. À un niveau élevé, cela permet aux organisations d'exploiter moins de ressources techniques pour mettre en œuvre BDD, libérant ainsi des ressources de développement et modifiant la zone de création, comme illustré ci-dessous.

Conclusion : la puissance et les défis du développement de logiciels BDD

BDD est une pratique de développement puissante qui peut garantir la création des fonctionnalités appropriées. Cependant, la mise à l'échelle du BDD au niveau de l'entreprise peut s'avérer difficile, car la mise en œuvre de cette pratique nécessite un large éventail 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'étapes sont exécutées comme SOAtest tests, ce qui rend la tâche beaucoup plus facile pour les testeurs et le personnel non technique à contribuer au processus de vérification. Parasoft Sélénic réduit la maintenance continue associée aux tests de l'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.