Che cos'è il Test Driven Development (TDD)? Esempio

Che cos'è il Test Driven Development (TDD)?

Sviluppo guidato dai test (TDD) è un approccio allo sviluppo del software in cui vengono sviluppati casi di test per specificare e convalidare ciò che farà il codice. In termini semplici, i casi di test per ciascuna funzionalità vengono prima creati e testati e se il test fallisce, viene scritto il nuovo codice per superare il test e rendere il codice semplice e privo di bug.

Lo sviluppo basato sui test inizia con la progettazione e lo sviluppo di test per ogni piccola funzionalità di un'applicazione. Il framework TDD indica agli sviluppatori di scrivere nuovo codice solo se un test automatizzato ha fallito. Ciò evita la duplicazione del codice. La forma completa del TDD è lo sviluppo basato sui test.

Il semplice concetto di TDD è scrivere e correggere i test falliti prima di scrivere nuovo codice (prima dello sviluppo). Ciò aiuta a evitare la duplicazione del codice poiché scriviamo una piccola quantità di codice alla volta per superare i test. (I test non sono altro che condizioni richieste che dobbiamo testare per soddisfarle).

Lo sviluppo basato sui test è un processo di sviluppo ed esecuzione di test automatizzati prima dello sviluppo effettivo dell'applicazione. Quindi, TDD a volte chiamato anche come Testare il primo sviluppo.

Come eseguire il test TDD

I passaggi seguenti definiscono come eseguire il test TDD,

Aggiungi una prova.
Esegui tutti i test e verifica se qualche nuovo test fallisce.
Scrivi del codice.
Esegui test e refactoring del codice.
Ripeti.

Definisce il ciclo TDD

Scrivi una prova
Fallo funzionare.
Modificare il codice per renderlo corretto, ad esempio Refactor.
Ripeti il processo.

Alcuni chiarimenti sul TDD:

L'approccio TDD non riguarda né il “test” né la “progettazione”.
TDD non significa “scrivere alcuni test, quindi costruire un sistema che superi i test”.
TDD non significa "fare molti test".

TDD vs. Test tradizionali

Di seguito è riportata la differenza principale tra lo sviluppo guidato dal test e il test tradizionale:

L'approccio TDD è principalmente una tecnica di specifica. Garantisce che il codice sorgente sia accuratamente testato a livello di conferma.

Con i test tradizionali, un test riuscito rileva uno o più difetti. È lo stesso del TDD. Quando un test fallisce, hai fatto progressi perché sai che devi risolvere il problema.
TDD garantisce che il tuo sistema soddisfi effettivamente i requisiti definiti per esso. Aiuta a rafforzare la fiducia nel tuo sistema.
In TDD l'attenzione è maggiore sul codice di produzione che verifica se i test funzioneranno correttamente. Nei test tradizionali, l’attenzione è maggiore sulla progettazione dei casi di test. Se il test mostrerà l'esecuzione corretta/errata dell'applicazione al fine di soddisfare i requisiti.
In TDD, ottieni un test di copertura del 100%. Ogni singola riga di codice viene testata, a differenza dei test tradizionali.
La combinazione sia del test tradizionale che del TDD porta all'importanza di testare il sistema piuttosto che del perfezionamento del sistema.
In Modellazione agile (AM), dovresti "testare con uno scopo". Dovresti sapere perché stai testando qualcosa e a quale livello è necessario testarlo.

Cos'è l'accettazione TDD e lo sviluppatore TDD

Esistono due livelli di TDD

TDD di accettazione (ATDD): Con ATDD scrivi un unico test di accettazione. Questo test soddisfa i requisiti delle specifiche o soddisfa il comportamento del sistema. Successivamente, scrivi il codice di produzione/funzionalità sufficiente per soddisfare il test di accettazione. Il test di accettazione si concentra sul comportamento generale del sistema. ATDD era anche conosciuto come Sviluppo comportamentale guidato (BDD).
TDD dello sviluppatore: Con Developer TDD scrivi un singolo test per sviluppatore, ovvero unit test, e quindi il codice di produzione appena sufficiente per soddisfare quel test. Il test unitario si concentra su ogni piccola funzionalità del sistema. Lo sviluppatore TDD si chiama semplicemente come TDD.L'obiettivo principale di ATDD e TDD è specificare requisiti dettagliati ed eseguibili per la soluzione in base al just in time (JIT). JIT significa prendere in considerazione solo i requisiti necessari nel sistema. Quindi aumenta l’efficienza.

Scalare il TDD tramite lo sviluppo agile basato su modelli (AMDD)

TDD è molto bravo nelle specifiche dettagliate e nella convalida. Non riesce a pensare a questioni più grandi come la progettazione complessiva, l’uso del sistema o l’interfaccia utente. AMDD risolve i problemi di ridimensionamento Agile che TDD non risolve.

Pertanto AMDD viene utilizzato per problemi più grandi.

Il ciclo di vita dell'AMDD

Nello sviluppo basato su modelli (MDD), vengono creati modelli estesi prima che il codice sorgente venga scritto. Che a loro volta hanno un approccio agile?

Nella figura sopra, ogni riquadro rappresenta un'attività di sviluppo.

L'envisioning è uno dei processi TDD di test di previsione/immaginazione che saranno eseguiti durante la prima settimana del progetto. L'obiettivo principale dell'envisioning è identificare l'ambito del sistema e l'architettura del sistema. Per un'envisioning di successo vengono eseguiti requisiti di alto livello e modellazione dell'architettura.

È il processo in cui non viene effettuata una specifica dettagliata del software/sistema ma si esplorano i requisiti del software/sistema che definisce la strategia complessiva del progetto.

Iterazione 0: Immaginazione

Ci sono due sotto-attivazioni principali.

Previsione dei requisiti iniziali.Potrebbero essere necessari diversi giorni per identificare i requisiti di alto livello e l'ambito del sistema. L'obiettivo principale è esplorare il modello di utilizzo, il modello di dominio iniziale e il modello di interfaccia utente (UI).
Iniziale Archivisione strutturale. Ci vogliono anche diversi giorni per identificare l'architettura del sistema. Consente di impostare le direzioni tecniche per il progetto. L'obiettivo principale è esplorare i diagrammi tecnologici, il flusso dell'interfaccia utente (UI), i modelli di dominio e i casi di modifica.

Modellazione di iterazione

Qui il team deve pianificare il lavoro che verrà svolto per ogni iterazione.

Il processo agile viene utilizzato per ogni iterazione, ovvero durante ogni iterazione, il nuovo elemento di lavoro verrà aggiunto con priorità.
Verranno presi in considerazione i primi lavori con priorità più elevata. È possibile ridefinire la priorità degli elementi di lavoro aggiunti o rimuoverli dalla pila di elementi in qualsiasi momento.
Il team discute su come implementare ciascun requisito. A questo scopo viene utilizzata la modellazione.
L'analisi e la progettazione della modellazione vengono eseguite per ciascun requisito che verrà implementato per tale iterazione.

Assalto ai modelli

Questo è anche noto come modellazione just in time.

Qui la sessione di modellazione coinvolge un team di 2/3 membri che discutono i problemi su carta o lavagna.
Un membro del team chiederà a un altro di modellare con lui. Questa sessione di modellazione richiederà circa 5-10 minuti. Dove i membri del team si riuniscono per condividere la lavagna/il foglio.
Esplorano i problemi finché non trovano la causa principale del problema. Appena in tempo, se un membro del team identifica il problema che desidera risolvere, si avvalerà del rapido aiuto degli altri membri del team.
Altri membri del gruppo esplorano quindi la questione e poi tutti continuano come prima. Viene anche chiamata modellazione stand-up o sessioni di QA del cliente.

Sviluppo guidato dai test (TDD)

Promuove test di conferma del codice applicativo e specifiche dettagliate.
Sia il test di accettazione (requisiti dettagliati) che i test di sviluppo (test unitario) sono input per TDD.
TDD rende il codice più semplice e chiaro. Consente allo sviluppatore di mantenere meno documentazione.

Recensioni

Questo è facoltativo. Include ispezioni del codice e revisioni dei modelli.
Questo può essere fatto per ogni iterazione o per l'intero progetto.
Questa è una buona opzione per fornire feedback per il progetto.

Sviluppo guidato dai test (TDD) vs. Sviluppo agile basato su modelli (AMDD)

TDD	AMDD
TDD accorcia il ciclo di feedback della programmazione	AMDD accorcia il ciclo di feedback della modellazione.
TDD è una specifica dettagliata	AMDD funziona per problemi più grandi
TDD promuove lo sviluppo di codice di alta qualità	AMDD promuove una comunicazione di alta qualità con le parti interessate e gli sviluppatori.
TDD parla ai programmatori	AMDD parla con Analista aziendale, parti interessate e professionisti dei dati.
TDD non orientato alla vista	AMDD orientato alla vista
TDD ha un ambito limitato ai lavori software	L'AMDD ha un campo d'azione ampio, che comprende anche le parti interessate. Implica lavorare verso una comprensione comune
Entrambi supportano lo sviluppo evolutivo	---------------

Quadri TDD

Ecco l'elenco dei migliori framework di sviluppo basato su test (TDD).

giunzione
TestNG
csUnit e NUnit
Rspec

Ora impariamo il Test Driven Development con l'esempio.

Esempio di TDD

Qui in questo esempio di Test Driven Development, definiremo una password di classe. Per questa classe, cercheremo di soddisfare le seguenti condizioni.

Una condizione per l'accettazione della password:

La password deve essere compresa tra 5 e 10 caratteri.

Innanzitutto in questo esempio TDD scriviamo il codice che soddisfa tutti i requisiti di cui sopra.

Scenario 1: Per eseguire il test creiamo la classe PasswordValidator();

Eseguiremo sopra la classe TestPassword ();

L'uscita è PASSATA come mostrato di seguito;

Uscita:

Scenario 2: Qui possiamo vedere che nel metodo TestPasswordLength () non è necessario creare un'istanza della classe PasswordValidator. Istanza significa creare un oggetto of class per fare riferimento ai membri (variabili/metodi) di quella classe.

Rimuoveremo la classe PasswordValidator pv = new PasswordValidator() dal codice. Possiamo chiamare il è valido () metodo direttamente da PasswordValidator. È valido (“Abc123”). (Vedi immagine sotto)

Quindi eseguiamo il refactoring (modifica del codice) come di seguito:

Scenario 3: Dopo il refactoring l'output mostra lo stato di errore (vedi immagine sotto) perché abbiamo rimosso l'istanza. Quindi non c'è alcun riferimento al metodo non statico è valido ().

Quindi dobbiamo modificare questo metodo aggiungendo la parola "statica" prima di Boolean poiché il booleano statico pubblico è valido (stringa password). Refactoring della classe PasswordValidator () per rimuovere l'errore precedente e superare il test.

Produzione:

Dopo aver apportato modifiche alla classe PassValidator (), se eseguiamo il test, l'output sarà PASSATO come mostrato di seguito.

Vantaggi del TDD

Di seguito sono riportati i principali vantaggi dello sviluppo guidato dai test nell'ingegneria del software:

Notifica anticipata del bug.

Gli sviluppatori testano il loro codice, ma nel mondo dei database questo spesso consiste in test manuali o script una tantum. Utilizzando TDD crei, nel tempo, una serie di test automatizzati che tu e qualsiasi altro sviluppatore potete rieseguire a piacimento.

Codice meglio progettato, più pulito e più estensibile.

Aiuta a capire come verrà utilizzato il codice e come interagisce con gli altri moduli.
Il risultato è una migliore decisione progettuale e un codice più gestibile.
TDD consente di scrivere codice più piccolo con responsabilità singola anziché procedure monolitiche con responsabilità multiple. Ciò rende il codice più semplice da comprendere.
TDD obbliga inoltre a scrivere solo codice di produzione per superare i test in base ai requisiti dell'utente.

Fiducia nel refactoring

Se si esegue il refactoring del codice, potrebbero esserci possibilità di interruzioni nel codice. Quindi, avendo una serie di test automatizzati, puoi correggere queste interruzioni prima del rilascio. Verrà fornito un avviso adeguato se vengono rilevate interruzioni durante l'utilizzo dei test automatizzati.
Utilizzando TDD, si dovrebbe ottenere un codice più veloce ed estensibile con meno bug che possono essere aggiornati con rischi minimi.

Buono per il lavoro di squadra

In assenza di qualsiasi membro del team, gli altri membri del team possono facilmente riprendere e lavorare sul codice. Aiuta inoltre la condivisione delle conoscenze, rendendo così il team complessivamente più efficace.

Buono per gli sviluppatori

Sebbene gli sviluppatori debbano dedicare più tempo alla scrittura dei casi di test TDD, ci vuole molto meno tempo per il debug e lo sviluppo di nuove funzionalità. Scriverai un codice più pulito e meno complicato.

Sommario

TDD sta per sviluppo basato sui test.
Significato TDD: è un processo di modifica del codice per superare un test progettato in precedenza.
Si pone maggiormente l'accento sul codice di produzione piuttosto che sulla progettazione del caso di test.
Lo sviluppo basato sui test è un processo di modifica del codice per superare un test progettato in precedenza.
In Software Engineering, A volte è noto come "Testare il primo sviluppo."
Il test TDD include il refactoring di un codice, ovvero la modifica/aggiunta di una certa quantità di codice al codice esistente senza influire sul comportamento del codice.
Programmazione TDD quando utilizzata, il codice diventa più chiaro e semplice da comprendere.

Potrebbe piacerti: