Sviluppo basato su test
Test Driven Development (TDD) è un approccio di sviluppo software in cui vengono sviluppati casi di test per specificare e convalidare ciò che il codice farà. In termini semplici, i casi di test per ciascuna funzionalità vengono creati e testati prima 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. TDD istruisce gli sviluppatori a scrivere nuovo codice solo se un test automatizzato ha avuto esito negativo. Ciò evita la duplicazione del codice. La forma completa di 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). Questo aiuta a evitare la duplicazione del codice mentre scriviamo una piccola quantità di codice alla volta per superare i test. (I test non sono altro che condizioni dei requisiti che dobbiamo testare per soddisfarli).
Lo sviluppo basato su test è un processo di sviluppo ed esecuzione di test automatizzati prima dello sviluppo effettivo dell'applicazione. Quindi, TDD a volte chiamato anche Test First Development.
In questo tutorial imparerai di più su-
- Come eseguire il test TDD
- TDD vs. Test tradizionali
- Cos'è l'accettazione TDD e Developer TDD
- Scalabilità del TDD tramite Agile Model Driven Development (AMDD)
- Test Driven Development (TDD) vs. Agile Model Driven Development (AMDD)
- Esempio di TDD
- Vantaggi di TDD
Come eseguire il test TDD
I passaggi seguenti definiscono come eseguire il test TDD,
- Aggiungi un test.
- Esegui tutti i test e verifica se un nuovo test fallisce.
- Scrivi del codice.
- Eseguire i test e il codice di refactoring.
- Ripetere.
Definisce il ciclo TDD
- Scrivi un test
- Fallo correre.
- Modificare il codice per renderlo corretto, ad esempio Refactoring.
- Ripeti il processo.
Alcuni chiarimenti su TDD:
- TDD non riguarda né il "Test" né il "Design".
- TDD non significa "scrivere alcuni dei test, quindi costruire un sistema che superi i test.
- TDD non significa "fare molti test".
TDD vs. Test tradizionali
L'approccio TDD è principalmente una tecnica di specifica. Assicura che il tuo codice sorgente sia accuratamente testato a livello di conferma.
- Con i test tradizionali, un test riuscito rileva uno o più difetti. È lo stesso di TDD. Quando un test fallisce, hai fatto progressi perché sai che devi risolvere il problema.
- TDD garantisce che il sistema soddisfi effettivamente i requisiti definiti per esso. Aiuta a costruire la tua fiducia sul tuo sistema.
- In TDD l'attenzione si concentra maggiormente sul codice di produzione che verifica se i test funzioneranno correttamente. Nei test tradizionali, l'attenzione si concentra maggiormente sulla progettazione del caso di test. Se il test mostrerà la corretta / impropria esecuzione dell'applicazione al fine di soddisfare i requisiti.
- In TDD, ottieni il test di copertura del 100%. Ogni singola riga di codice viene testata, a differenza dei test tradizionali.
- La combinazione di test tradizionali e TDD porta all'importanza di testare il sistema piuttosto che alla perfezione del sistema.
- In Agile Modeling (AM), dovresti "testare con uno scopo". Dovresti sapere perché stai testando qualcosa e quale livello deve essere testato.
Cos'è l'accettazione TDD e Developer TDD
Esistono due livelli di TDD
- Accettazione TDD (ATDD): Con ATDD scrivi un unico test di accettazione. Questo test soddisfa i requisiti della specifica o soddisfa il comportamento del sistema. Dopodiché scrivi il codice di produzione / funzionalità sufficiente per completare il test di accettazione. Il test di accettazione si concentra sul comportamento generale del sistema. ATDD era anche noto come Behavioral Driven Development (BDD).
- Developer TDD: con Developer TDD scrivi un test per singolo sviluppatore, cioè un test unitario e quindi il codice di produzione sufficiente per completare quel test. Lo unit test si concentra su ogni piccola funzionalità del sistema. Lo sviluppatore TDD è chiamato semplicemente TDD.
L'obiettivo principale di ATDD e TDD è specificare requisiti dettagliati ed eseguibili per la soluzione su base just in time (JIT). JIT significa prendere in considerazione solo quei requisiti che sono necessari nel sistema. Quindi aumenta l'efficienza.
Scalabilità del TDD tramite Agile Model Driven Development (AMDD)
TDD è molto bravo nelle specifiche dettagliate e nella convalida. Non riesce a pensare a problemi più grandi come il design generale, l'uso del sistema o l'interfaccia utente. AMDD risolve i problemi di scalabilità Agile che TDD non fa.
Così AMDD utilizzato per problemi più grandi.
Il ciclo di vita di AMDD.
In Model-driven Development (MDD), vengono creati modelli estesi prima della scrittura del codice sorgente. Che a loro volta hanno un approccio agile?
Nella figura sopra, ogni riquadro rappresenta un'attività di sviluppo.
Envisioning è uno dei processi TDD di previsione / immaginazione dei test che verranno eseguiti durante la prima settimana del progetto. L'obiettivo principale della visione è identificare l'ambito del sistema e l'architettura del sistema. Requisiti di alto livello e modellazione dell'architettura vengono eseguiti per una visione di successo.
È il processo in cui non viene eseguita una specifica dettagliata del software / sistema, ma l'esplorazione dei requisiti del software / sistema che definisce la strategia complessiva del progetto.
- Iterazione 0: Envisioning
Ci sono due principali sottoattivazioni.
- 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).
- Progettazione architettonica iniziale.
Inoltre, sono necessari diversi giorni per identificare l'architettura del sistema. Consente di impostare indicazioni 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, cioè durante ogni iterazione, il nuovo elemento di lavoro verrà aggiunto con priorità.
- Verrà preso in considerazione il primo lavoro con priorità più alta. Gli elementi di lavoro aggiunti possono essere ridefiniti o rimossi dalla pila degli elementi in qualsiasi momento.
- Il team discute come implementeranno ogni requisito. La modellazione viene utilizzata per questo scopo.
- L'analisi e la progettazione della modellazione vengono eseguite per ogni requisito che verrà implementato per tale iterazione.
- Modello storming:
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 loro. Questa sessione di modellazione richiederà circa 5-10 minuti. Dove i membri del team si riuniscono per condividere lavagna / carta.
- Esplorano i problemi finché non trovano la causa principale del problema. Appena in tempo, se un membro del team identifica il problema che vuole risolvere, allora si rivolgerà rapidamente agli altri membri del team.
- Gli altri membri del gruppo esplorano quindi il problema e poi tutti continuano come prima. Viene anche chiamato come modellazione stand-up o sessioni di controllo qualità del cliente.
- Test Driven Development (TDD).
- Promuove il test di conferma del codice dell'applicazione e le specifiche dettagliate.
- Sia il test di accettazione (requisiti dettagliati) che i test per sviluppatori (test unitario) sono input per TDD.
- TDD rende il codice più semplice e chiaro. Consente allo sviluppatore di conservare meno documentazione.
- Recensioni.
- Questo è opzionale. Include le ispezioni del codice e le 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.
Test Driven Development (TDD) vs. Agile Model Driven Development (AMDD)
| TDD | AMDD |
|
|
|
|
|
|
|
|
|
|
|
|
| -------------------------------------------- |
Esempio di TDD
In questo esempio, definiremo una password di classe. Per questa classe, cercheremo di soddisfare le seguenti condizioni.
Una condizione per l'accettazione della password:
- La password deve contenere da 5 a 10 caratteri.
Per prima cosa, 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 è SUPERATA come mostrato di seguito;
Uscita :
Scenario 2 : qui possiamo vedere nel metodo TestPasswordLength () non è necessario creare un'istanza della classe PasswordValidator. Istanza significa creare un oggetto di classe per fare riferimento ai membri (variabili / metodi) di quella classe.
Rimuoveremo la classe PasswordValidator pv = new PasswordValidator () dal codice. Possiamo chiamare il metodo isValid () direttamente da PasswordValidator. IsValid ("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 (vedere l'immagine sotto) perché abbiamo rimosso l'istanza. Quindi non vi è alcun riferimento al metodo non statico isValid ().
Quindi abbiamo bisogno di cambiare questo metodo aggiungendo una parola "statica" prima di Boolean come booleano statico pubblico isValid (String password). Refactoring della classe PasswordValidator () per rimuovere l'errore sopra riportato per superare il test.
Produzione:
Dopo aver apportato modifiche alla classe PassValidator (), se eseguiamo il test, l'output verrà SUPERATO come mostrato di seguito.
Vantaggi di TDD
- Notifica tempestiva dei bug.
Gli sviluppatori testano il loro codice, ma nel mondo dei database, questo spesso consiste in test manuali o script una tantum. Usando TDD crei, nel tempo, una suite di test automatizzati che tu e qualsiasi altro sviluppatore potete rieseguire a piacimento.
- Codice progettato meglio, più pulito e più estensibile.
- Aiuta a capire come verrà utilizzato il codice e come interagisce con altri moduli.
- Il risultato è una migliore decisione di progettazione e un codice più gestibile.
- TDD consente di scrivere codice più piccolo con responsabilità singola piuttosto che procedure monolitiche con responsabilità multiple. Ciò rende il codice più semplice da capire.
- TDD impone inoltre di scrivere solo il codice di produzione per superare i test in base ai requisiti dell'utente.
- Fiducia nel refactoring
- Se esegui il refactoring del codice, possono esserci possibilità di interruzioni nel codice. Quindi, disponendo di una serie di test automatici, è possibile correggere tali interruzioni prima del rilascio. Se vengono rilevate interruzioni durante l'utilizzo di test automatizzati, verrà fornito un avviso appropriato.
- L'utilizzo di TDD dovrebbe comportare 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, altri membri del team possono facilmente raccogliere e lavorare sul codice. Aiuta anche la condivisione delle conoscenze, rendendo così il team più efficiente nel complesso.
- Buono per gli sviluppatori
Sebbene gli sviluppatori debbano dedicare più tempo alla scrittura di 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 è l'acronimo di Test-driven development. È un processo di modifica del codice per superare un test progettato in precedenza.
- Dà più enfasi al codice di produzione piuttosto che al design del test case.
- Lo sviluppo basato su test è un processo di modifica del codice per superare un test progettato in precedenza.
- Nell'ingegneria del software, a volte è noto come "Test First Development".
- 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.
- TDD quando viene utilizzato, il codice diventa più chiaro e semplice da capire.
Questo articolo è fornito da Kanchan Kulkarni