tdd vs bdd analyze differences with examples
Aquest tutorial explica les diferències entre TDD i BDD amb exemples:
TDD o Test Driven Development i BDD o Behavior Driven Development són les dues tècniques de desenvolupament de programari.
Abans d’endinsar-nos en la diferència entre aquests dos, entenguem primer què signifiquen individualment i com s’utilitzen?
Comencem!!
Què aprendreu:
Què és TDD?
TDD significa Test Driven Development. En aquesta tècnica de desenvolupament de programari, primer creem els casos de prova i després escrivim el codi subjacent a aquests casos de prova. Tot i que TDD és una tècnica de desenvolupament, també es pot utilitzar per al desenvolupament de proves d'automatització.
Els equips que implementen TDD triguen més temps a desenvolupar-se, però solen trobar molt pocs defectes. TDD resulta en una millora de la qualitat del codi i del codi que és més reutilitzable i flexible.
TDD també ajuda a assolir el màxim cobertura de la prova d'aproximadament el 90-100%. El més difícil per als desenvolupadors que segueixen TDD és escriure els casos de prova abans d’escriure el codi.
Lectura suggerida => Guia definitiva per escriure casos de prova excel·lents
Procés de TDD
La metodologia TDD segueix un procés de 6 passos molt senzill:
1) Escriviu un cas de prova: En funció dels requisits, escriviu un cas de prova automatitzat.
2) Executeu tots els casos de prova: Executeu aquests casos de prova automàtics al codi desenvolupat actualment.
3) Elaboreu el codi per als casos de prova: Si el cas de prova falla, escriviu el codi per fer que el cas de prova funcioni com s’esperava.
4) Torneu a executar casos de prova: Torneu a executar els casos de prova i comproveu si tots els casos de prova desenvolupats fins ara estan implementats.
5) Refactoritzeu el vostre codi: Aquest és un pas opcional. Tot i això, és important que es refactoritzi el codi per fer-lo més llegible i reutilitzable.
6) Repetiu els passos 1-5 per als casos de prova nous: Repetiu el cicle per als altres casos de prova fins que s’implementin tots els casos de prova.
Exemple d'implementació d'un cas de prova a TDD
Suposem que tenim el requisit de desenvolupar una funcionalitat d’inici de sessió per a una aplicació que tingui camps de nom d’usuari i contrasenya i un botó d’enviament.
Pas 1: Creeu un cas de prova.
@Test Public void checkLogin(){ LoginPage.enterUserName('UserName'); LoginPage.enterPassword('Password'); HomePage homePage = LoginPage.submit(); Assert.assertNotNull(homePage); } 
Pas 2: Executeu aquest cas de prova i obtindrem un error que diu que la pàgina d'inici de sessió no està definida i que no hi ha mètodes amb noms enterUserName, enterPassword i submit.
converteix char a cadena c ++
Pas 3: Desenvolupeu el codi per a aquest cas de prova. Escrivim el codi subjacent que introduirà el nom d’usuari i la contrasenya i obtindrem un objecte de pàgina inicial quan siguin correctes.
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(); } } } 
Pas 4: Torneu a executar el cas de prova i obtindrem una instància de la pàgina inicial.
Pas 5: Refactoritzem el codi per donar els missatges d’error correctes quan les condicions del mètode d’enviament no són certes.
//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'); } Pas 6: Ara anem a escriure un cas de prova nou amb un nom d’usuari i una contrasenya buits.
@Test Public void checkLogin(){ LoginPage.enterUserName(''); LoginPage.enterPassword(''); HomePage homePage = LoginPage.submit(); Assert.assertNotNull(homePage); } Ara, si proveu d'executar aquest cas de prova, fallarà. Repetiu els passos 1 a 5 per a aquest cas de prova i, a continuació, afegiu la funcionalitat per gestionar cadenes de nom d'usuari i contrasenya buides.
Què és BDD?
BDD significa Behavior Driven Development. BDD és una extensió a TDD, en lloc d’escriure els casos de prova, comencem escrivint un comportament. Més endavant, desenvolupem el codi que és necessari perquè la nostra aplicació realitzi el comportament.
L'escenari definit en l'enfocament BDD facilita la col·laboració dels desenvolupadors, verificadors i usuaris empresarials.
El BDD es considera una bona pràctica quan es tracta proves automatitzades ja que se centra en el comportament de l'aplicació i no en pensar en la implementació del codi.
El comportament de l’aplicació és el centre d’enfocament de BDD i obliga els desenvolupadors i els provadors a entrar en la pell del client.
Procés de BDD
El procés implicat en la metodologia BDD també consta de 6 passos i és molt similar al de TDD.
1) Escriviu el comportament de l'aplicació: El comportament d’una aplicació s’escriu en anglès senzill, com l’idioma del propietari del producte o dels analistes empresarials o dels QAs.
2) Escriviu els scripts automatitzats: Aquest simple anglès com a idioma es converteix en proves de programació.
3) Implementar el codi funcional: A continuació, s’implementa el codi funcional subjacent al comportament.
4) Comproveu si el comportament té èxit: Executeu el comportament i vegeu si té èxit. Si és correcte, passeu al següent comportament, en cas contrari, corregiu els errors del codi funcional per aconseguir el comportament de l'aplicació.
5) Refactorització o organització del codi: Refactoritzeu o organitzeu el vostre codi per fer-lo més llegible i reutilitzable.
6) Repetiu els passos 1-5 per obtenir un comportament nou: Repetiu els passos per implementar més comportaments a la vostra aplicació.
Llegiu també => Com participen els verificadors en les tècniques TDD, BDD i ATDD
Exemple d'implementació de comportament a BDD
Suposem que tenim el requisit de desenvolupar una funcionalitat d’inici de sessió per a una aplicació que tingui camps de nom d’usuari i contrasenya i un botó d’enviament.
Pas 1: Escriviu el comportament de l'aplicació per introduir el nom d'usuari i la contrasenya.
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.Pas 2: Escriviu l'script de prova automatitzat per a aquest comportament tal com es mostra a continuació.
@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); } }Pas 3: Implementa el codi funcional (és similar al codi funcional de l'exemple 3 del pas TDD).
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(); } } }Pas 4: Executeu aquest comportament i comproveu si té èxit. Si té èxit, aneu al pas 5 en cas contrari, depureu la implementació funcional i torneu-la a executar.
Pas 5: Refactoritzar la implementació és un pas opcional i, en aquest cas, podem refactoritzar el codi del mètode d'enviament per imprimir els missatges d'error tal com es mostra al pas 5 per a 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'); } Pas 6: Escriviu un comportament diferent i seguiu els passos 1 a 5 per a aquest comportament nou.
Podem escriure un comportament nou per comprovar si obtenim un error per no introduir el nom d’usuari tal com es mostra a continuació:
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 contra BDD: diferències clau
| TDD | BDD |
|---|---|
| Pot ser un millor enfocament per a projectes que impliquin eines de tercers i API. | Pot ser un millor enfocament per als projectes que es basen en les accions dels usuaris. Per exemple: lloc web de comerç electrònic, sistema d'aplicacions, etc. |
| Suports per al desenvolupament impulsat per proves. | Suports per al desenvolupament impulsat pel comportament. |
| El procés comença escrivint un cas de prova. | El procés comença escrivint un escenari segons el comportament esperat. |
| TDD se centra en com s’implementa la funcionalitat. | BDD se centra en el comportament d'una aplicació per a l'usuari final. |
| Els casos de prova s’escriuen en un llenguatge de programació. | Els escenaris són més llegibles en comparació amb TDD, ja que s’escriuen en format anglès senzill. |
| Canvis en la manera com les funcions de l'aplicació impacten molt en els casos de prova de TDD. | Els canvis de funcionalitat no afecten molt els escenaris BDD. |
| La col·laboració només és necessària entre els desenvolupadors. | Cal col·laborar entre tots els grups d'interès. |
| Algunes de les eines que admeten TDD són: JUnit, TestNG, NUnit, etc. | Algunes de les eines que admeten BDD són SpecFlow, Cucumber, MSpec, etc. |
| Les proves en TDD només les poden entendre persones amb coneixements de programació, | Les proves en BDD poden ser enteses per qualsevol persona, incloses les que no tinguin cap coneixement de programació. |
| TDD redueix la probabilitat de tenir errors a les proves. | Els errors de les proves són difícils de rastrejar si es compara amb TDD. |
Conclusió
Triar entre TDD i BDD pot ser molt complicat. Alguns podrien argumentar que BDD és millor per trobar errors mentre que els altres només podrien dir que TDD proporciona una cobertura de codi més elevada.
Cap de les dues metodologies és millor que l’altra. Depèn de la persona i de l’equip del projecte per decidir quina metodologia utilitzar.
Esperem que aquest article hagi esborrat els vostres dubtes sobre TDD vs BDD !!
Lectura recomanada
- Exemple de proves d'aplicacions web de més de 180 casos de proves (llista de comprovació de mostres)
- Com es tradueixen casos de prova manuals a scripts d'automatització? - Una guia pas a pas amb exemple
- Preguntes d’entrevistes sobre casos de prova: escriviu casos de prova segons l’escenari
- Com participen els verificadors en les tècniques TDD, BDD i ATDD
- Cobertura de proves en proves de programari (consells per maximitzar la cobertura de proves)
- 8 millors eines i marcs de proves per al desenvolupament impulsat pel comportament (BDD)
- Tutorial Specflow: la Guia definitiva de l'eina BDD
- Com escriure casos de prova: la guia definitiva amb exemples