tdd vs bdd analyze differences with examples
Questo tutorial spiega le differenze tra TDD e BDD con esempi:
TDD o Test Driven Development e BDD o Behavior Driven Development sono le due tecniche di sviluppo del software.
Prima di immergerci più a fondo nella differenza tra questi due, dobbiamo prima capire cosa significano individualmente e come vengono utilizzati?
Iniziamo!!
app per carte del tempo libero per Android
Cosa imparerai:
Cos'è il TDD?
TDD è l'acronimo di Test Driven Development. In questa tecnica di sviluppo software, creiamo prima i casi di test e poi scriviamo il codice sottostante a questi casi di test. Sebbene TDD sia una tecnica di sviluppo, può essere utilizzata anche per lo sviluppo di test di automazione.
I team che implementano TDD impiegano più tempo per lo sviluppo, tuttavia, tendono a trovare pochissimi difetti. TDD si traduce in una migliore qualità del codice e il codice è più riutilizzabile e flessibile.
TDD aiuta anche a raggiungere alti copertura di prova di circa il 90-100%. La cosa più difficile per gli sviluppatori che seguono TDD è scrivere i loro casi di test prima di scrivere il codice.
Lettura suggerita => Guida definitiva per la scrittura di casi di test eccellenti
Processo di TDD
La metodologia TDD segue un processo in 6 fasi molto semplice:
1) Scrivi un test case: In base ai requisiti, scrivi un test case automatizzato.
2) Esegui tutti i casi di test: Esegui questi casi di test automatizzati sul codice attualmente sviluppato.
3) Sviluppa il codice per quei casi di test: Se il test case fallisce, scrivi il codice per farlo funzionare come previsto.
4) Esegui di nuovo i casi di test: Esegui nuovamente i casi di test e controlla se tutti i casi di test sviluppati finora sono implementati.
5) Refactoring del codice: Questo è un passaggio facoltativo. Tuttavia, è importante effettuare il refactoring del codice per renderlo più leggibile e riutilizzabile.
6) Ripetere i passaggi da 1 a 5 per i nuovi casi di test: Ripetere il ciclo per gli altri casi di test fino a quando tutti i casi di test non sono stati implementati.
Esempio di implementazione di uno scenario di test in TDD
Supponiamo di avere un requisito per sviluppare una funzionalità di accesso per un'applicazione che abbia campi nome utente e password e un pulsante di invio.
Passo 1: Crea uno scenario di test.
@Test Public void checkLogin(){ LoginPage.enterUserName('UserName'); LoginPage.enterPassword('Password'); HomePage homePage = LoginPage.submit(); Assert.assertNotNull(homePage); }
Passo 2: Esegui questo test case e riceveremo un errore che dice che la pagina di accesso non è definita e non ci sono metodi con nomi enterUserName, enterPassword e submit.
Step3: Sviluppa il codice per quel test case. Scriviamo il codice sottostante che inserirà il nome utente e la password e otterremo un oggetto della home page quando saranno corretti.
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(); } } }
Step4: Esegui di nuovo lo scenario di test e otterremo un'istanza della home page.
Step5: Effettuiamo il refactoring del codice per fornire i messaggi di errore corretti quando le condizioni if nel metodo submit non sono vere.
//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'); }
Step6: Ora scriviamo un nuovo caso di test con un nome utente e una password vuoti.
@Test Public void checkLogin(){ LoginPage.enterUserName(''); LoginPage.enterPassword(''); HomePage homePage = LoginPage.submit(); Assert.assertNotNull(homePage); }
Ora se provi a eseguire questo test case, fallirà. Ripetere i passaggi da 1 a 5 per questo test case, quindi aggiungere la funzionalità per gestire le stringhe di nome utente e password vuote.
Cos'è BDD?
BDD è l'acronimo di Behavior Driven Development. BDD è un'estensione di TDD in cui invece di scrivere i casi di test, iniziamo scrivendo un comportamento. Successivamente, sviluppiamo il codice necessario alla nostra applicazione per eseguire il comportamento.
Lo scenario definito nell'approccio BDD facilita la collaborazione tra sviluppatori, tester e utenti aziendali.
BDD è considerata una best practice quando si tratta di test automatizzati in quanto si concentra sul comportamento dell'applicazione e non sul pensare all'implementazione del codice.
Il comportamento dell'applicazione è il centro dell'attenzione in BDD e costringe gli sviluppatori e i tester a entrare nei panni del cliente.
Processo di BDD
Anche il processo coinvolto nella metodologia BDD consiste in 6 passaggi ed è molto simile a quello del TDD.
1) Scrivi il comportamento dell'applicazione: Il comportamento di un'applicazione è scritto in un semplice inglese come il linguaggio dal proprietario del prodotto, dagli analisti aziendali o dai QA.
2) Scrivi gli script automatici: Questo semplice linguaggio simile all'inglese viene quindi convertito in test di programmazione.
3) Implementare il codice funzionale: Il codice funzionale alla base del comportamento viene quindi implementato.
4) Controlla se il comportamento ha successo: Esegui il comportamento e verifica se ha successo. In caso di esito positivo, passare al comportamento successivo, altrimenti correggere gli errori nel codice funzionale per ottenere il comportamento dell'applicazione.
java j2ee intervista domande e risposte per esperti
5) Refactoring o organizzare il codice: Rifattorizza o organizza il tuo codice per renderlo più leggibile e riutilizzabile.
6) Ripeti i passaggi 1-5 per un nuovo comportamento: Ripeti i passaggi per implementare più comportamenti nella tua applicazione.
Leggi anche => Come i tester sono coinvolti nelle tecniche TDD, BDD e ATDD
Esempio di implementazione del comportamento in BDD
Supponiamo di avere un requisito per sviluppare una funzionalità di accesso per un'applicazione che abbia campi nome utente e password e un pulsante di invio.
Passo 1: Scrivi il comportamento dell'applicazione per l'inserimento del nome utente e della password.
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.
Passo 2: Scrivi lo script di test automatizzato per questo comportamento come mostrato di seguito.
@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); } }
Step3: Implementare il codice funzionale (questo è simile al codice funzionale nel passaggio 3 dell'esempio 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(); } } }
Step4: Esegui questo comportamento e verifica se ha successo. Se ha esito positivo, andare al passaggio 5 altrimenti eseguire il debug dell'implementazione funzionale e quindi eseguirlo di nuovo.
Step5: Il refactoring dell'implementazione è un passaggio facoltativo e, in questo caso, possiamo refactoring del codice nel metodo submit per stampare i messaggi di errore come mostrato nel passaggio 5 per l'esempio 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'); }
Step6: Scrivi un comportamento diverso e segui i passaggi da 1 a 5 per questo nuovo comportamento.
Possiamo scrivere un nuovo comportamento per verificare se otteniamo un errore per non aver immesso il nome utente come mostrato di seguito:
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 - Differenze chiave
TDD | BDD |
---|---|
Potrebbe essere un approccio migliore per i progetti che coinvolgono API e strumenti di terze parti. | Potrebbe essere un approccio migliore per i progetti che sono guidati dalle azioni degli utenti. Ad esempio: sito web di e-commerce, sistema applicativo, ecc. |
È l'acronimo di Test Driven Development. | È l'acronimo di Behavior Driven Development. |
Il processo inizia scrivendo un test case. | Il processo inizia scrivendo uno scenario secondo il comportamento previsto. |
TDD si concentra su come viene implementata la funzionalità. | BDD si concentra sul comportamento di un'applicazione per l'utente finale. |
I casi di test sono scritti in un linguaggio di programmazione. | Gli scenari sono più leggibili rispetto a TDD poiché sono scritti in un semplice formato inglese. |
I cambiamenti nel modo in cui le funzioni dell'applicazione influiscono molto sui casi di test in TDD. | Gli scenari BDD non sono molto influenzati dalle modifiche alle funzionalità. |
La collaborazione è richiesta solo tra gli sviluppatori. | È necessaria la collaborazione tra tutti gli stakeholder. |
Alcuni degli strumenti che supportano TDD sono: JUnit, TestNG, NUnit, ecc. | Alcuni degli strumenti che supportano BDD sono SpecFlow, Cucumber, MSpec, ecc. |
I test in TDD possono essere compresi solo da persone con conoscenze di programmazione, | I test in BDD possono essere compresi da chiunque, compresi quelli senza alcuna conoscenza di programmazione. |
TDD riduce la probabilità di avere bug nei test. | I bug nei test sono difficili da tracciare rispetto al TDD. |
Conclusione
La scelta tra TDD e BDD può essere molto complicata. Alcuni potrebbero obiettare che BDD è migliore per trovare bug, mentre altri potrebbero semplicemente dire che TDD offre una maggiore copertura del codice.
Nessuna metodologia è migliore dell'altra. Dipende dalla persona e dal team di progetto per decidere quale metodologia utilizzare.
Speriamo che questo articolo abbia chiarito i tuoi dubbi su TDD vs BDD !!
Lettura consigliata
- 180+ casi di test di esempio di test di applicazioni Web (elenco di controllo di esempio)
- Come tradurre casi di test manuali in script di automazione? - Una guida passo passo con esempi
- Domande di intervista di casi di test: scrivere casi di test in base allo scenario
- Come i tester sono coinvolti nelle tecniche TDD, BDD e ATDD
- Copertura dei test nei test del software (suggerimenti per massimizzare la copertura dei test)
- 8 Migliori strumenti di sviluppo guidato dal comportamento (BDD) e framework di test
- Tutorial Specflow: la guida definitiva allo strumento BDD
- Come scrivere casi di test: la guida definitiva con esempi