tdd vs bdd analyze differences with examples
Denne opplæringen forklarer forskjellene mellom TDD og BDD med eksempler:
TDD eller testdrevet utvikling og BDD eller atferdsdrevet utvikling er de to teknikkene for programvareutvikling.
Før vi dykker dypere inn i forskjellen mellom disse to, la oss først forstå hva de mener hver for seg og hvordan brukes de?
La oss begynne!!
test nettsted for sårbarhet for SQL-injeksjon
Hva du vil lære:
Hva er TDD?
TDD står for Test Driven Development. I denne programvareutviklingsteknikken lager vi først testtilfellene og skriver deretter koden som ligger til grunn for disse testtilfellene. Selv om TDD er en utviklingsteknikk, kan den også brukes til utvikling av automatiseringstesting.
Teamene som implementerer TDD tar mer tid for utvikling, men de har en tendens til å finne svært få feil. TDD resulterer i forbedret kvalitet på koden og koden som er mer gjenbrukbar og fleksibel.
TDD hjelper også til å oppnå høyt testdekning 90-100%. Det mest utfordrende for utviklere som følger TDD, er å skrive testsakene sine før de skriver koden.
Foreslått lese => Ultimate Guide for Writing Excellent Test Cases
Prosess med TDD
TDD-metodikk følger en veldig enkel 6-trinnsprosess:
1) Skriv en prøvesak: Basert på kravene, skriv en automatisert testsak.
2) Kjør alle testtilfellene: Kjør disse automatiserte testtilfellene på den nåværende utviklede koden.
3) Utvik koden for de testtilfellene: Hvis testsaken mislykkes, så skriv koden for å få den testsaken til å fungere som forventet.
4) Kjør testtilfeller igjen: Kjør testsakene på nytt og sjekk om alle testsakene som er utviklet så langt er implementert.
5) Omformer koden din: Dette er et valgfritt trinn. Det er imidlertid viktig å omformulere koden din for å gjøre den mer lesbar og gjenbrukbar.
6) Gjenta trinn 1-5 for nye testtilfeller: Gjenta syklusen for de andre testsakene til alle testsakene er implementert.
Eksempel på en implementering av en testsak i TDD
La oss anta at vi har et krav om å utvikle en påloggingsfunksjonalitet for et program som har brukernavn og passordfelt og en sendeknapp.
Trinn 1: Lag en prøvesak.
@Test Public void checkLogin(){ LoginPage.enterUserName('UserName'); LoginPage.enterPassword('Password'); HomePage homePage = LoginPage.submit(); Assert.assertNotNull(homePage); } 
Steg 2: Kjør dette testtilfellet, og vi får en feil som sier at påloggingssiden ikke er definert, og det er ingen metoder med navnene EnterUserName, enterPassword og send.
Trinn 3: Utvikle koden for den prøvesaken. La oss skrive den underliggende koden som vil angi brukernavn og passord og få et startsideobjekt når de er riktige.
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(); } } } 
Trinn 4: Kjør testsaken på nytt, så får vi en forekomst av hjemmesiden.
Trinn 5: La oss omforme koden for å gi de riktige feilmeldingene når betingelsene i sendemetoden ikke er sanne.
//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'); } Trinn 6: La oss nå skrive en ny testsak med et tomt brukernavn og passord.
@Test Public void checkLogin(){ LoginPage.enterUserName(''); LoginPage.enterPassword(''); HomePage homePage = LoginPage.submit(); Assert.assertNotNull(homePage); } Hvis du prøver å kjøre denne testsaken, mislykkes den nå. Gjenta trinn 1 til 5 for denne testsaken, og legg deretter til funksjonaliteten for å håndtere tomme brukernavn og passordstrenger.
Hva er BDD?
BDD står for Behavior Driven Development. BDD er en utvidelse til TDD der vi i stedet for å skrive testsaker starter med å skrive en oppførsel. Senere utvikler vi koden som kreves for at applikasjonen vår skal utføre oppførselen.
Scenariet definert i BDD-tilnærmingen gjør det enkelt for utviklere, testere og forretningsbrukere å samarbeide.
BDD regnes som en best praksis når det gjelder automatisert testing da den fokuserer på oppførselen til applikasjonen og ikke på å tenke på implementeringen av koden.
Oppførselen til applikasjonen er sentrum for fokus i BDD, og det tvinger utviklerne og testerne til å gå inn i kundens sko.
Prosessen med BDD
Prosessen involvert i BDD-metodikk består også av seks trinn og er veldig lik TDD.
1) Skriv oppførselen til applikasjonen: Oppførselen til en applikasjon er skrevet på enkelt engelsk som språk av produktseieren eller forretningsanalytikerne eller kvalitetssikringsselskapene.
Python intervju spørsmål og svar for testere
2) Skriv de automatiserte skriptene: Dette enkle engelsklignende språket blir deretter konvertert til programmeringstester.
3) Implementere funksjonskoden: Den funksjonelle koden som ligger til grunn for atferden blir deretter implementert.
4) Sjekk om oppførselen er vellykket: Kjør oppførselen og se om den lykkes. Hvis det lykkes, kan du gå til neste oppførsel ellers fikse feilene i funksjonskoden for å oppnå applikasjonsatferden.
5) Refaktor eller organiser kode: Refaktoriser eller organiser koden for å gjøre den mer lesbar og gjenbrukbar.
6) Gjenta trinn 1-5 for ny oppførsel: Gjenta trinnene for å implementere mer atferd i applikasjonen din.
Les også => Hvordan testere er involvert i TDD-, BDD- og ATDD-teknikker
Eksempel på atferdsimplementering i BDD
La oss anta at vi har et krav om å utvikle en påloggingsfunksjonalitet for et program som har brukernavn og passordfelt og en sendeknapp.
Trinn 1: Skriv oppførselen til applikasjonen for å skrive inn brukernavn og passord.
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.Steg 2: Skriv det automatiserte testskriptet for denne oppførselen 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); } }Trinn 3: Implementere funksjonskoden (Dette ligner på funksjonskoden i TDD eksempel trinn 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(); } } }Trinn 4: Kjør denne oppførselen og se om den er vellykket. Hvis det lykkes, så gå til trinn 5, ellers feilsøk den funksjonelle implementeringen og kjør den igjen.
Trinn 5: Refactoring av implementeringen er et valgfritt trinn, og i dette tilfellet kan vi omlegge koden i sendemetoden for å skrive ut feilmeldingene som vist i trinn 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'); } Trinn 6: Skriv en annen oppførsel og følg trinn 1 til 5 for denne nye oppførselen.
Vi kan skrive en ny oppførsel for å sjekke om vi får en feil for ikke å skrive inn brukernavnet 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økkelforskjeller
| TDD | BDD |
|---|---|
| Kan være en bedre tilnærming for prosjekter som involverer API og tredjepartsverktøy. | Kan være en bedre tilnærming for prosjekter som er drevet av brukerhandlinger. For eksempel: e-handelsnettsted, applikasjonssystem osv. |
| Står for testdrevet utvikling. | Står for atferdsdrevet utvikling. |
| Prosessen starter med å skrive en prøvesak. | Prosessen starter med å skrive et scenario i henhold til forventet oppførsel. |
| TDD fokuserer på hvordan funksjonaliteten implementeres. | BDD fokuserer på oppførselen til en applikasjon for sluttbrukeren. |
| Test tilfeller er skrevet på et programmeringsspråk. | Scenarier er mer lesbare sammenlignet med TDD, ettersom de er skrevet i enkelt engelsk format. |
| Endringer i hvordan applikasjonen fungerer påvirker mye på testtilfellene i TDD. | BDD-scenarier påvirkes ikke mye av funksjonalitetsendringene. |
| Samarbeid er kun nødvendig mellom utviklerne. | Det kreves samarbeid mellom alle interessentene. |
| Noen av verktøyene som støtter TDD er: JUnit, TestNG, NUnit, etc. | Noen av verktøyene som støtter BDD er SpecFlow, Agurk, MSpec, etc. |
| Tester i TDD kan bare forstås av personer med programmeringskunnskap, | Tester i BDD kan forstås av enhver person, inkludert de uten noen programmeringskunnskap. |
| TDD reduserer sannsynligheten for å ha feil i testene dine. | Feil i tester er vanskelig å spore sammenlignet med TDD. |
Konklusjon
Å velge mellom TDD vs BDD kan være veldig vanskelig. Noen vil kanskje hevde at BDD er bedre for å finne feil, mens de andre kanskje bare sier at TDD gir høyere kodedekning.
Ingen av metodene er bedre enn den andre. Det avhenger av personen og prosjektgruppen å bestemme hvilken metode som skal brukes.
Vi håper denne artikkelen har fjernet tvilen din om TDD vs BDD !!
Anbefalt lesing
- 180+ testeksempler på nettapplikasjonstester (prøvesjekkliste)
- Hvordan oversette manuelle testtilfeller til automatiseringsskript? - En trinnvis guide med eksempel
- Testtilfeller Intervju spørsmål: Skriv testtilfeller basert på scenario
- Hvordan testere er involvert i TDD, BDD og ATDD teknikker
- Testdekning i programvaretesting (tips for å maksimere testdekning)
- 8 Best Behavior Driven Development (BDD) verktøy og testrammer
- Specflow Tutorial: The Ultimate Guide to BDD Tool
- Hvordan skrive testsaker: Den ultimate guiden med eksempler