Découvrez quelle solution de test API est arrivée en tête dans le rapport GigaOm Radar. Obtenez votre rapport d'analyse gratuit >>

Découvrez quelle solution de test API est arrivée en tête dans le rapport GigaOm Radar. Obtenez votre rapport d'analyse gratuit >>
Aller à la section
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.
Aller à la section
Aller à la section
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 ?
BDD est une évolution du méthodologie de développement piloté par les tests (TDD), dans lequel les développeurs écrivent le test avant é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.
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.
Le développement axé sur les entreprises présente plusieurs avantages pour le développement de logiciels. Avec BDD, vous pouvez :
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.
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é.
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.
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:
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.
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.
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.
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.
Rapport GigaOm Radar pour les tests fonctionnels automatisés des API