Menu

TDD vs BDD - Analyser forskellene med eksempler

tdd vs bdd analyze differences with examples

Prøv Vores Instrument Til At Fjerne Problemer

Denne vejledning forklarer forskellene mellem TDD og BDD med eksempler:

TDD eller Test Driven Development og BDD eller Behavior Driven Development er de to softwareudviklingsteknikker.

Før vi dykker dybere ned i forskellen mellem disse to, lad os først forstå, hvad de betyder individuelt, og hvordan bruges de?

Lad os begynde!!

TDD mod BDD

port udløser vs port videresendelse til spil

Hvad du lærer:

Hvad er TDD?

TDD står for Test Driven Development. I denne softwareudviklingsteknik opretter vi først testcases og skriver derefter koden, der ligger til grund for disse testcases. Selvom TDD er en udviklingsteknik, kan den også bruges til automatiseringstestudvikling.

De hold, der implementerer TDD, tager mere tid til udvikling, men de har tendens til at finde meget få fejl. TDD resulterer i forbedret kvalitet af koden og den kode, der er mere genanvendelig og fleksibel.

TDD hjælper også med at opnå høj test dækning 90-100%. Det mest udfordrende for udviklere, der følger TDD, er at skrive deres testsager, før de skriver koden.

Foreslået læsning => Ultimate Guide til skrivning af fremragende testtilfælde

Process af TDD

TDD-metoden følger en meget enkel 6-trins proces:

1) Skriv en test case: Baseret på kravene, skriv en automatiseret test case.

2) Kør alle testcases: Kør disse automatiserede testsager på den aktuelt udviklede kode.

3) Udvikl koden til de testsager: Hvis testsagen mislykkes, skal du skrive koden for at få denne testsag til at fungere som forventet.

4) Kør testcases igen: Kør testsagerne igen, og kontroller, om alle de hidtil udviklede testsager er implementeret.

5) Refaktor din kode: Dette er et valgfrit trin. Det er dog vigtigt at omlægge din kode for at gøre den mere læsbar og genanvendelig.

6) Gentag trin 1-5 for nye testsager: Gentag cyklussen for de andre testsager, indtil alle testsagerne er implementeret.

TDD-flowdiagram

Eksempel på implementering af en testsag i TDD

Lad os antage, at vi har et krav om at udvikle en loginfunktionalitet til en applikation, der har brugernavn og adgangskodefelter og en sendeknap.

Trin 1: Opret en test case.

@Test Public void checkLogin(){ LoginPage.enterUserName('UserName'); LoginPage.enterPassword('Password'); HomePage homePage = LoginPage.submit(); Assert.assertNotNull(homePage); }

TDD test sag

Trin 2: Kør denne testtilfælde, og vi får en fejl, der siger, at login-siden ikke er defineret, og der er ingen metoder med navne enterUserName, enterPassword og send.

Trin 3: Udvikl koden til den test sag. Lad os skrive den underliggende kode, som vil indtaste brugernavnet og adgangskoden og få et startsideobjekt, når de er korrekte.

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(); } } }

TDD Test Case Eksempel

Trin 4: Kør testsagen igen, så får vi en forekomst af startsiden.

Trin 5: Lad os omlægge koden for at give de korrekte fejlmeddelelser, når betingelserne i afsendemetoden ikke er sande.

//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'); }

Trin 6: Lad os nu skrive en ny test sag med et tomt brugernavn og en adgangskode.

@Test Public void checkLogin(){ LoginPage.enterUserName(''); LoginPage.enterPassword(''); HomePage homePage = LoginPage.submit(); Assert.assertNotNull(homePage); }

Hvis du nu prøver at køre denne test sag, vil den mislykkes. Gentag trin 1 til 5 for denne test sag, og tilføj derefter funktionaliteten til at håndtere tomme brugernavne og adgangskode strenge.

Hvad er BDD?

BDD står for Behavior Driven Development. BDD er en udvidelse til TDD, hvor vi i stedet for at skrive testsagerne starter med at skrive en adfærd. Senere udvikler vi den kode, der kræves for at vores applikation kan udføre adfærden.

Scenariet defineret i BDD-tilgangen gør det let for udviklere, testere og forretningsbrugere at samarbejde.

BDD betragtes som en bedste praksis, når det kommer til automatiseret test da det fokuserer på applikationens opførsel og ikke på at tænke på implementeringen af ​​koden.

Applikationens opførsel er centrum for BDD, og ​​det tvinger udviklerne og testerne til at gå i kundens sko.

Process med BDD

Processen involveret i BDD-metoden består også af 6 trin og svarer meget til processen med TDD.

1) Skriv applikationens opførsel: En ansøgnings opførsel er skrevet på simpelt engelsk som sprog af produktsejeren eller forretningsanalytikerne eller kvalitetssikringsselskaberne.

2) Skriv de automatiserede scripts: Dette enkle engelsklignende sprog konverteres derefter til programmeringstest.

3) Implementere funktionskoden: Den funktionelle kode, der ligger til grund for adfærden, implementeres derefter.

4) Kontroller, om opførslen er vellykket: Kør adfærden og se om den er vellykket. Hvis det lykkes, skal du gå til den næste adfærd, ellers skal du rette fejlene i funktionskoden for at opnå applikationsadfærden.

hvordan man spiller .mkv filer på windows

5) Refaktor eller organiser kode: Omformuler eller organiser din kode for at gøre den mere læselig og genanvendelig.

6) Gentag trin 1-5 for ny opførsel: Gentag trinene for at implementere mere adfærd i din applikation.

Læs også => Hvordan testere er involveret i TDD-, BDD- og ATDD-teknikker

Eksempel på implementering af adfærd i BDD

Lad os antage, at vi har et krav om at udvikle en loginfunktionalitet til en applikation, der har brugernavn og adgangskodefelter og en sendeknap.

Trin 1: Skriv applikationens opførsel til indtastning af brugernavn og adgangskode.

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.

Trin 2: Skriv det automatiske testscript for denne opførsel som vist nedenfor.

@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); } }

Trin 3: Implementere funktionskoden (Dette svarer til funktionskoden i TDD-eksempel, trin 3).

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(); } } }

Trin 4: Kør denne adfærd, og se om den er vellykket. Hvis det lykkes, skal du gå til trin 5, ellers fejlret den funktionelle implementering og kør den igen.

Trin 5: Refactoring af implementeringen er et valgfrit trin, og i dette tilfælde kan vi omlægge koden i afsendemetoden for at udskrive fejlmeddelelserne som vist i trin 5 for TDD-eksemplet.

//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'); }

Trin 6: Skriv en anden adfærd, og følg trin 1 til 5 for denne nye adfærd.

Vi kan skrive en ny adfærd for at kontrollere, om vi får en fejl for ikke at indtaste brugernavnet som vist nedenfor:

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 - Nøgleforskelle

TDDBDD
Kan være en bedre tilgang til projekter, der involverer API og tredjepartsværktøjer.Kan være en bedre tilgang til projekter, der er drevet af brugerhandlinger. For eksempel: e-handelswebsted, applikationssystem osv.
Står for testdrevet udvikling.Står for adfærdsdrevet udvikling.
Processen starter med at skrive en testsag.Processen starter med at skrive et scenario i henhold til den forventede adfærd.
TDD fokuserer på, hvordan funktionaliteten implementeres.BDD fokuserer på opførelsen af ​​en applikation til slutbrugeren.
Testcases er skrevet på et programmeringssprog.Scenarier er mere læsbare sammenlignet med TDD, da de er skrevet i simpelt engelsk format.
Ændringer i, hvordan applikationen fungerer, har stor indflydelse på testsagerne i TDD.BDD-scenarier påvirkes ikke meget af funktionalitetsændringerne.
Der kræves kun samarbejde mellem udviklerne.Der kræves samarbejde mellem alle interessenter.
Nogle af de værktøjer, der understøtter TDD, er: JUnit, TestNG, NUnit osv.Nogle af de værktøjer, der understøtter BDD, er SpecFlow, Agurk, MSpec osv.
Test i TDD kan kun forstås af personer med programmeringskendskab,Test i BDD kan forstås af enhver person inklusive dem uden nogen programmeringsviden.
TDD reducerer sandsynligheden for, at der er bugs i dine tests.Fejl i test er svære at spore sammenlignet med TDD.

Konklusion

At vælge mellem TDD vs BDD kan være meget vanskeligt. Nogle hævder måske, at BDD er bedre til at finde fejl, mens de andre måske bare siger, at TDD giver højere kodedækning.

Ingen af ​​metoderne er bedre end den anden. Det afhænger af personen og projektteamet at afgøre, hvilken metode der skal bruges.

Vi håber, at denne artikel har ryddet din tvivl om TDD vs BDD !!

Anbefalet læsning

^