tdd vs bdd analyze differences with examples
Ce didacticiel explique les différences entre TDD et BDD avec des exemples:
TDD ou Test Driven Development et BDD ou Behavior Driven Development sont les deux techniques de développement logiciel.
Avant de plonger plus profondément dans la différence entre ces deux, comprenons d'abord ce qu'ils signifient individuellement et comment sont-ils utilisés?
Commençons!!
VPN Allemagne gratuit
Ce que vous apprendrez:
Qu'est-ce que le TDD?
TDD signifie Test Driven Development. Dans cette technique de développement logiciel, nous créons d'abord les cas de test, puis nous écrivons le code sous-jacent à ces cas de test. Bien que le TDD soit une technique de développement, il peut également être utilisé pour le développement de tests d'automatisation.
Les équipes qui implémentent TDD, prennent plus de temps pour le développement cependant, elles ont tendance à trouver très peu de défauts. Le TDD améliore la qualité du code et le code est plus réutilisable et flexible.
TDD aide également à atteindre des Couverture de test d'environ 90 à 100%. La chose la plus difficile pour les développeurs qui suivent TDD est d'écrire leurs cas de test avant d'écrire le code.
Lecture suggérée => Guide ultime pour rédiger d'excellents cas de test
Processus de TDD
La méthodologie TDD suit un processus très simple en 6 étapes:
1) Ecrire un cas de test: En fonction des exigences, rédigez un cas de test automatisé.
2) Exécutez tous les cas de test: Exécutez ces cas de test automatisés sur le code actuellement développé.
3) Développez le code pour ces cas de test: Si le scénario de test échoue, écrivez le code pour que ce scénario de test fonctionne comme prévu.
4) Exécutez à nouveau les cas de test: Exécutez à nouveau les cas de test et vérifiez si tous les cas de test développés jusqu'à présent sont implémentés.
5) Refactorisez votre code: Ceci est une étape optionnelle. Cependant, il est important de refactoriser votre code pour le rendre plus lisible et réutilisable.
6) Répétez les étapes 1 à 5 pour les nouveaux cas de test: Répétez le cycle pour les autres cas de test jusqu'à ce que tous les cas de test soient implémentés.
Exemple d'implémentation d'un scénario de test dans TDD
Supposons que nous ayons l'obligation de développer une fonctionnalité de connexion pour une application comportant des champs de nom d'utilisateur et de mot de passe et un bouton d'envoi.
Étape 1: Créez un scénario de test.
@Test Public void checkLogin(){ LoginPage.enterUserName('UserName'); LoginPage.enterPassword('Password'); HomePage homePage = LoginPage.submit(); Assert.assertNotNull(homePage); }
Étape 2: Exécutez ce scénario de test et nous obtiendrons une erreur indiquant que la page de connexion n'est pas définie et qu'il n'y a pas de méthodes avec des noms enterUserName, enterPassword et soumettre.
Étape 3: Développez le code pour ce cas de test. Écrivons le code sous-jacent qui entrera le nom d'utilisateur et le mot de passe et obtiendra un objet de page d'accueil lorsqu'ils sont corrects.
public class LoginPage{ String username; String password; //store username public void enterUserName(String username){ this.username = username; } //store password public void enterPassword(String password){ this.password = password; } //match username and passowrd in db and return home page public HomePage submit(){ if(username.existsInDB()){ String dbPassword = getPasswordFromDB(username); if(dbPassword.equals(password){ Return new HomePage(); } } }
Étape 4: Exécutez à nouveau le scénario de test et nous obtiendrons une instance de la page d'accueil.
Étape 5: Refactorisons le code pour donner les bons messages d'erreur lorsque les conditions if de la méthode d'envoi ne sont pas vraies.
//match username and passowrd in db and return home page public HomePage submit(){ if(username.existsInDB()){ String dbPassword = getPasswordFromDB(username); if(dbPassword.equals(password){ Return new HomePage(); } else{ System.out.println('Please provide correct password'); return; } } else{ System.out.println('Please provide correct username'); }
Étape 6: Écrivons maintenant un nouveau scénario de test avec un nom d'utilisateur et un mot de passe vides.
@Test Public void checkLogin(){ LoginPage.enterUserName(''); LoginPage.enterPassword(''); HomePage homePage = LoginPage.submit(); Assert.assertNotNull(homePage); }
Maintenant, si vous essayez d'exécuter ce scénario de test, il échouera. Répétez les étapes 1 à 5 pour ce scénario de test, puis ajoutez la fonctionnalité permettant de gérer les chaînes de nom d'utilisateur et de mot de passe vides.
Qu'est-ce que BDD?
BDD signifie Behavior Driven Development. BDD est une extension de TDD où au lieu d'écrire les cas de test, nous commençons par écrire un comportement. Plus tard, nous développons le code requis pour que notre application exécute le comportement.
Le scénario défini dans l'approche BDD permet aux développeurs, testeurs et utilisateurs métier de collaborer facilement.
BDD est considérée comme une bonne pratique en matière de tests automatisés car il se concentre sur le comportement de l'application et non sur la réflexion sur l'implémentation du code.
Le comportement de l’application est au centre des préoccupations de BDD et oblige les développeurs et les testeurs à se mettre à la place du client.
Processus de BDD
Le processus impliqué dans la méthodologie BDD comprend également 6 étapes et est très similaire à celui du TDD.
1) Ecrivez le comportement de l'application: Le comportement d'une application est rédigé en anglais simple comme la langue par le propriétaire du produit ou les analystes commerciaux ou les QA.
2) Écrivez les scripts automatisés: Ce simple langage anglais est ensuite converti en tests de programmation.
3) Implémentez le code fonctionnel: Le code fonctionnel sous-jacent au comportement est ensuite implémenté.
4) Vérifiez si le comportement est réussi: Exécutez le comportement et voyez s'il réussit. En cas de succès, passez au comportement suivant, sinon corrigez les erreurs dans le code fonctionnel pour obtenir le comportement de l'application.
5) Refactoriser ou organiser le code: Refactorisez ou organisez votre code pour le rendre plus lisible et réutilisable.
6) Répétez les étapes 1 à 5 pour un nouveau comportement: Répétez les étapes pour implémenter plus de comportements dans votre application.
Lire aussi => Comment les testeurs sont impliqués dans les techniques TDD, BDD et ATDD
Exemple d'implémentation de comportement dans BDD
Supposons que nous ayons l'obligation de développer une fonctionnalité de connexion pour une application comportant des champs de nom d'utilisateur et de mot de passe et un bouton d'envoi.
Étape 1: Écrivez le comportement de l'application pour entrer le nom d'utilisateur et le mot de passe.
Scenario: Login check Given I am on the login page When I enter 'username' username And I enter 'Password' password And I click on the 'Login' button Then I am able to login successfully.
Étape 2: Écrivez le script de test automatisé pour ce comportement comme indiqué ci-dessous.
@RunWith(Cucumber.class) public class MyStepDefinitions { @Steps LoginPage loginPage; @Steps HomePage hp; @Given('^I am on the login page $') public void i_am_on_the_login_page(){ loginPage.gotoLoginPage(); } @When('^I enter '((^')*)' username$') public void i_enter_something_username(String username) { loginPage.enterUserName(username); } @When('^I enter '((^')*)' password$') public void i_enter_something_password(String password) { loginPage.enterPassword(password); } @When('^I click on the '((^')*)' button$') public void i_click_on_the_submit_button(String strArg1) { hp = loginPage.submit(); } @Then('^I am able to login successfully.$') public void i_am_able_to_login_successfully() { Assert.assertNotNull(hp); } }
Étape 3: Implémentez le code fonctionnel (Ceci est similaire au code fonctionnel de l'étape 3 de l'exemple TDD).
entrée et sortie de fichier c ++
public class LoginPage{ String username = ''; String password = ''; //store username public void enterUserName(String username){ this.username = username; } //store password public void enterPassword(String password){ this.password = password; } //match username and passowrd in db and return home page public HomePage submit(){ if(username.existsInDB()){ String dbPassword = getPasswordFromDB(username); if(dbPassword.equals(password){ Return new HomePage(); } } }
Étape 4: Exécutez ce comportement et voyez s'il réussit. S'il réussit, passez à l'étape 5, sinon déboguez l'implémentation fonctionnelle et réexécutez-la.
Étape 5: Refactoriser l'implémentation est une étape facultative et dans ce cas, nous pouvons refactoriser le code dans la méthode submit pour imprimer les messages d'erreur comme indiqué à l'étape 5 pour l'exemple TDD.
//match username and passowrd in db and return home page public HomePage submit(){ if(username.existsInDB()){ String dbPassword = getPasswordFromDB(username); if(dbPassword.equals(password){ Return new HomePage(); } else{ System.out.println('Please provide correct password'); return; } } else{ System.out.println('Please provide correct username'); }
Étape 6: Écrivez un comportement différent et suivez les étapes 1 à 5 pour ce nouveau comportement.
Nous pouvons écrire un nouveau comportement pour vérifier si nous obtenons une erreur pour ne pas entrer le nom d'utilisateur comme indiqué ci-dessous:
Scenario: Login check Given I am on the login page And I click on the 'Login' button Then I get an error to enter username.
TDD Vs BDD - Différences clés
TDD | BDD |
---|---|
Peut-être une meilleure approche pour les projets qui impliquent des API et des outils tiers. | Peut-être une meilleure approche pour les projets qui sont motivés par les actions des utilisateurs. Par exemple: site Web de commerce électronique, système d'application, etc. |
Stands pour Test Driven Development. | Stands for Behavior Driven Development. |
Le processus commence par écrire un cas de test. | Le processus commence par écrire un scénario selon le comportement attendu. |
TDD se concentre sur la manière dont la fonctionnalité est mise en œuvre. | BDD se concentre sur le comportement d'une application pour l'utilisateur final. |
Les cas de test sont écrits dans un langage de programmation. | Les scénarios sont plus lisibles par rapport à TDD car ils sont écrits dans un format anglais simple. |
Les changements dans la façon dont les fonctions de l'application ont un impact important sur les cas de test dans TDD. | Les scénarios BDD ne sont pas beaucoup impactés par les changements de fonctionnalités. |
La collaboration n'est requise qu'entre les développeurs. | Une collaboration est nécessaire entre toutes les parties prenantes. |
Certains des outils qui prennent en charge TDD sont: JUnit, TestNG, NUnit, etc. | Certains des outils qui prennent en charge BDD sont SpecFlow, Cucumber, MSpec, etc. |
Les tests en TDD ne peuvent être compris que par des personnes ayant des connaissances en programmation, | Les tests en BDD peuvent être compris par toute personne, y compris celles sans aucune connaissance en programmation. |
TDD réduit la probabilité d'avoir des bogues dans vos tests. | Les bogues dans les tests sont difficiles à suivre par rapport à TDD. |
Conclusion
Le choix entre TDD Vs BDD peut être très délicat. Certains pourraient affirmer que BDD est meilleur pour trouver des bogues, tandis que d'autres pourraient simplement dire que TDD offre une couverture de code plus élevée.
Aucune de ces méthodes n'est meilleure que l'autre. Cela dépend de la personne et de l'équipe du projet pour décider de la méthodologie à utiliser.
Nous espérons que cet article a dissipé vos doutes sur TDD vs BDD !!
lecture recommandée
- 180+ exemples de tests d'application Web (exemple de liste de contrôle)
- Comment traduire des cas de test manuels en scripts d'automatisation? - Un guide étape par étape avec un exemple
- Questions d'entrevue de cas de test: rédiger des cas de test en fonction du scénario
- Comment les testeurs sont impliqués dans les techniques TDD, BDD et ATDD
- Couverture des tests dans les tests logiciels (conseils pour maximiser la couverture des tests)
- 8 Meilleurs outils de développement orienté comportement (BDD) et cadres de test
- Tutoriel Specflow: Le guide ultime de l'outil BDD
- Comment rédiger des cas de test: le guide ultime avec des exemples