BDD - Sviluppo basato su test
Quando guardi qualsiasi riferimento sullo sviluppo guidato dal comportamento, troverai l'uso di frasi come "BDD è derivato da TDD", "BDD e TDD". Per sapere come è nato BDD, perché si dice che derivi da TDD e cosa sono BDD e TDD, devi avere una comprensione di TDD.
Perché testare?
Per iniziare, entriamo nei fondamenti del test. Lo scopo del test è garantire che il sistema creato funzioni come previsto. Considera il seguente esempio.
Quindi, per esperienza abbiamo imparato che scoprire un difetto man mano che viene introdotto e risolverlo immediatamente sarebbe conveniente. Pertanto, è necessario scrivere casi di test in ogni fase di sviluppo e test. Questo è ciò che ci hanno insegnato le nostre pratiche di test tradizionali, che spesso viene definito Test-early.
Questo approccio di test è definito come l'approccio Test-Last poiché il test viene eseguito dopo il completamento di una fase.
Sfide con l'approccio Test-Last
L'approccio Test-Last è stato seguito per parecchio tempo nei progetti di sviluppo software. Tuttavia, in realtà, con questo approccio, poiché il test deve attendere fino al completamento di una determinata fase, spesso viene trascurato a causa di:
I ritardi nel completamento della tappa.
Tempi stretti.
Concentrati sulla consegna in tempo, saltando i test.
Inoltre, nell'approccio Test-Last, il test unitario, che dovrebbe essere fatto dagli sviluppatori, viene spesso ignorato. Le varie ragioni trovate si basano sulla mentalità degli sviluppatori -
Sono sviluppatori e non tester.
Il test è responsabilità dei tester.
Sono efficienti nella codifica e il loro codice non avrebbe difetti.
Ciò si traduce in -
Compromettere la qualità del prodotto consegnato.
Avere la responsabilità per la qualità solo sui tester.
Elevati costi per la riparazione dei difetti, post consegna.
Incapacità di ottenere la soddisfazione del cliente, il che significherebbe anche la perdita di affari ripetuti, con conseguente credibilità.
Questi fattori hanno richiesto un cambiamento di paradigma, per concentrarsi sui test. Il risultato è stato l'approccio Test-First.
Approccio test-first
L'approccio Test-First sostituisce il modo di sviluppo inside-out (scrivere codice e poi test) con quello outside-in (scrivere test e poi codice).
Questo approccio è incorporato nelle seguenti metodologie di sviluppo software (che sono anche Agile):
eXtreme Programming (XP).
Test Dlacerato Dsviluppo (TDD).
In queste metodologie, lo sviluppatore progetta e scrive gli Unit test per un modulo di codice prima di scrivere una singola riga del modulo di codice. Lo sviluppatore crea quindi il modulo di codice con l'obiettivo di superare lo unit test. Pertanto, queste metodologie utilizzano i test unitari per guidare lo sviluppo.
Il punto fondamentale è notare che l'obiettivo è lo sviluppo basato sul test.
Ciclo Red-Green-Refactor
Test Driven Development viene utilizzato per sviluppare il codice guidato dagli unit test.
Step 1 - Considera un modulo di codice che deve essere scritto.
Step 2 - Scrivi un test
Step 3 - Esegui il test.
Il test fallisce, poiché il codice non è ancora stato scritto. Quindi, il passaggio 2 viene solitamente indicato come scrivere un test per fallire.
Step 4 - Scrivere il codice minimo possibile per superare il test.
Step 5- Esegui tutti i test per assicurarti che vengano comunque superati. I test unitari sono automatizzati per facilitare questo passaggio.
Step 6 - Refactoring.
Step 7 - Ripetere i passaggi da 1 a 6 per il modulo di codice successivo.
Ogni ciclo dovrebbe essere molto breve e un'ora tipica dovrebbe contenere molti cicli.
Questo è anche popolarmente noto come Red-Green-Refactor ciclo, dove -
Red - Scrivere un test che fallisce.
Green - Scrittura del codice per superare il test.
Refactor - Rimuovere la duplicazione e migliorare il codice secondo standard accettabili.
Fasi del processo TDD
Le fasi di un processo TDD sono illustrate di seguito.
Vantaggi di TDD
I vantaggi o i vantaggi di Test Driven Development sono:
Lo sviluppatore deve prima capire quale dovrebbe essere il risultato desiderato e come testarlo prima di creare il codice.
Il codice di un componente è terminato solo quando il test viene superato e il codice viene riformattato. Ciò garantisce il test e il refactoring prima che lo sviluppatore passi al test successivo.
Poiché la suite di unit test viene eseguita dopo ogni refactoring, il feedback che ogni componente sta ancora funzionando è costante.
Gli unit test fungono da documentazione vivente che è sempre all'altezza dei dati.
Se viene rilevato un difetto, lo sviluppatore crea un test per rivelare quel difetto e quindi modifica il codice in modo che il test venga superato e il difetto venga risolto. Ciò riduce il tempo di debug. Vengono eseguiti anche tutti gli altri test e quando passano, si assicura che la funzionalità esistente non venga interrotta
Lo sviluppatore può prendere decisioni di progettazione e refactoring in qualsiasi momento e l'esecuzione dei test garantisce che il sistema funzioni ancora. Ciò rende il software gestibile.
Lo sviluppatore ha la certezza di apportare qualsiasi modifica poiché se la modifica influisce su una funzionalità esistente, la stessa viene rivelata eseguendo i test ei difetti possono essere riparati immediatamente.
Ad ogni ciclo di prova successivo vengono verificate anche tutte le correzioni di difetti precedenti e la ripetizione dello stesso difetto viene ridotta.
Poiché la maggior parte dei test viene eseguita durante lo sviluppo stesso, il test prima della consegna viene ridotto.
Svantaggi di TDD
Il punto di partenza sono le User Story, che descrivono il comportamento del sistema. Pertanto, gli sviluppatori affrontano spesso le seguenti domande:
Quando eseguire il test?
Cosa provare?
Come sapere se una specifica è soddisfatta?
Il codice offre valore aziendale?
Idee sbagliate su TDD
Le seguenti idee sbagliate esistono nel settore e necessitano di chiarimenti.
| Idea sbagliata | Una precisazione |
|---|---|
| TDD è interamente dedicato al testing e all'automazione dei test. | TDD è una metodologia di sviluppo che utilizza l'approccio Test-First. |
| TDD non prevede alcun design. | TDD include analisi critiche e progettazione basata sui requisiti. Il design emerge durante lo sviluppo. |
| TDD è solo a livello di unità. | TDD può essere utilizzato a livello di integrazione e di sistema. |
| TDD non può essere utilizzato dai tradizionali progetti di test. | TDD è diventato popolare con Extreme Programming e viene utilizzato in altre metodologie Agile. Tuttavia, può essere utilizzato anche in progetti di test tradizionali. |
| TDD è uno strumento. | TDD è una metodologia di sviluppo e, dopo che ogni nuovo Unit Test viene superato, viene aggiunto all'Automation Test Suite poiché tutti i test devono essere eseguiti ogni volta che viene aggiunto un nuovo codice o viene modificato il codice esistente e anche dopo ogni refactoring. Pertanto, gli strumenti di automazione del test che supportano TDD facilitano questo processo. |
| TDD significa consegnare i test di accettazione agli sviluppatori. | TDD non significa consegnare i test di accettazione agli sviluppatori. |
Accettazione TDD
L'Acceptance Test Driven Development (ATDD) definisce i criteri di accettazione e i test di accettazione durante la creazione delle User Story, all'inizio dello sviluppo. ATDD si concentra sulla comunicazione e sulla comprensione comune tra i clienti, gli sviluppatori e i tester.
Le pratiche chiave in ATDD sono le seguenti:
Discuti gli scenari del mondo reale per costruire una comprensione condivisa del dominio.
Usa questi scenari per arrivare ai criteri di accettazione.
Automatizza i test di accettazione.
Concentra lo sviluppo su quei test.
Usa i test come specifiche in tempo reale per facilitare il cambiamento.
I vantaggi dell'utilizzo di ATDD sono i seguenti:
I requisiti sono inequivocabili e senza lacune funzionali.
Altri capiscono i casi speciali previsti dagli sviluppatori.
I test di accettazione guidano lo sviluppo.
TDD Vs BDD
Secondo Dan North, i programmatori normalmente affrontano i seguenti problemi durante l'esecuzione di Test Driven Development:
Dove iniziare
Cosa testare e cosa non testare
Quanto testare in una volta
Come chiamare i loro test
Come capire perché un test fallisce
La soluzione a tutti questi problemi è lo sviluppo guidato dal comportamento. Si è evoluto dalle pratiche agili consolidate ed è progettato per renderli più accessibili ed efficaci per i team, nuovi alla distribuzione agile del software. Nel tempo, BDD è cresciuta fino a comprendere il quadro più ampio dell'analisi agile e dei test di accettazione automatizzati.
Il principale difference between TDD and BDD è quello -
TDD descrive come funziona il software.
D'altra parte, BDD -
Descrive come l'utente finale utilizza il software.
Favorisce la collaborazione e la comunicazione.
Sottolinea gli esempi di comportamento del sistema.
Mira alle specifiche eseguibili derivate dagli esempi