{"id":21422,"date":"2021-08-27T11:02:08","date_gmt":"2021-08-27T09:02:08","guid":{"rendered":"https:\/\/www.software-developer-india.com\/che-cose-lo-sviluppo-guidato-dai-test-o-tdd\/"},"modified":"2021-08-27T11:02:15","modified_gmt":"2021-08-27T09:02:15","slug":"che-cose-lo-sviluppo-guidato-dai-test-o-tdd","status":"publish","type":"post","link":"https:\/\/www.software-developer-india.com\/it\/che-cose-lo-sviluppo-guidato-dai-test-o-tdd\/","title":{"rendered":"Che cos’\u00e8 lo sviluppo guidato dai test? O TDD?"},"content":{"rendered":"\n

Che cos’\u00e8 lo sviluppo guidato dai test? O TDD?<\/h2>\n\n
\"\"<\/a><\/figure><\/div>\n\n

Test Driven Development o TDD, come \u00e8 affettuosamente noto nei circoli degli sviluppatori, \u00e8 un aspetto importante del processo di sviluppo del software. Attraverso questo approccio, \u00e8 pi\u00f9 facile testare le prestazioni di un codice specifico. Vengono creati casi di test per ogni funzionalit\u00e0 dell’applicazione software e, quando una particolare funzionalit\u00e0 non riesce in un test, il codice viene rielaborato e vengono creati nuovi codici. Il nuovo codice dovrebbe anche superare il test ed essere privo di bug. Lo sviluppatore deve scrivere un nuovo codice solo se il test automatizzato per il codice non \u00e8 riuscito, quindi ci sar\u00e0 un test case per ogni funzionalit\u00e0, per quanto piccola possa essere. E TDD riguarda la progettazione e lo sviluppo di test per ogni singola funzionalit\u00e0 dell’applicazione. <\/p>\n\n

Il nome Test Driven Development indica che \u00e8 il processo di fare i test nel modo giusto che guida lo sviluppo del software. Quindi, il processo stesso trae le sue radici dalla metodologia Agile e dalla programmazione Extreme. Questo processo garantisce che gli sviluppatori creino e mantengano un codice resiliente ea lungo termine. <\/p>\n\n

Quindi il processo per TDD sarebbe scrivere prima il test dell’unit\u00e0 e, se il test fallisce, implementare le modifiche al codice. Questo aiuta anche a evitare la duplicazione del codice. Il tutto si basa sulla scrittura e sulla correzione di test falliti prima dello sviluppo effettivo. Tuttavia, affinch\u00e9 il TDD funzioni correttamente, sarebbe consigliabile scrivere i casi di test in casi di test semplici. Per una logica aziendale complessa, sarebbe davvero difficile scrivere una combinazione di casi di test e ottenere il pieno successo. C’\u00e8 la possibilit\u00e0 che tu possa perdere la scrittura di alcuni test, quindi non \u00e8 affatto un compito facile. <\/p>\n\n

Differenza tra TDD e test tradizionale<\/strong><\/h3>\n\n

I test tradizionali richiedono pi\u00f9 tempo rispetto a TDD e si basano sulla ripetizione di un breve ciclo di sviluppo. Prima viene scritto il test dall’inizio, quindi viene scritto il codice del programma, seguito dal comportamento desiderato del sistema. Al superamento della prova scritta (verifica della correttezza del lavoro del codice non scritto), viene eseguito il refactoring del codice scritto. <\/p>\n\n

Inizialmente, anche TDD richieder\u00e0 molto tempo, ma nel tempo lo sviluppatore si abituer\u00e0 perch\u00e9 il processo di sviluppo diventer\u00e0 pi\u00f9 strutturato. Ad esempio, quando assumi uno sviluppatore, decider\u00e0 cosa scrivere e poi come scriverlo. <\/p>\n\n

Il test tradizionale ha successo quando trova correttamente uno o pi\u00f9 difetti. Proprio come TDD. Trovare i difetti \u00e8 in realt\u00e0 un buon segno perch\u00e9 allora sai che devi risolvere ci\u00f2 che non va e andare avanti da l\u00ec. TDD ti d\u00e0 anche pi\u00f9 fiducia quando rilasci il programma e assicura che soddisfi i requisiti per i quali \u00e8 definito. <\/p>\n\n

Nei test tradizionali, l’attenzione si concentra maggiormente sulla progettazione dei casi di test, mentre in TDD l’attenzione si concentra maggiormente sul codice di produzione per verificare se il test funzioner\u00e0 secondo i piani. <\/p>\n\n

TDD ti offre una copertura del test del 100%, in cui il test viene eseguito per ogni singola riga di codice, non \u00e8 il caso dei test tradizionali.<\/p>\n\n

Quando l’ambito del progetto \u00e8 davvero ampio, devi essere molto accurato durante lo svolgimento dei test. E c’\u00e8 la possibilit\u00e0 che i test subiscano ritardi e superino i limiti di budget e tempo. <\/p>\n\n

TDD potrebbe essere difficile da scrivere e potrebbe rallentare i tempi di sviluppo, ma sicuramente pagherebbe nel lungo periodo. <\/p>\n\n

Un altro svantaggio di TDD \u00e8 che il concetto \u00e8 difficile da applicare al codice legacy esistente. <\/p>\n\n

\u00c8 sempre bene che il test fallisca prima di rilasciare un progetto, perch\u00e9 cos\u00ec saprai di aver eseguito un test valido. Attraverso TDD, saprai che il tuo sistema soddisfa i requisiti per i quali \u00e8 stato progettato. Quindi l’attenzione si concentra maggiormente sul codice di produzione per TDD, in quanto garantisce che il test funzioni correttamente. E quando il software soddisfa tutti i requisiti progettati per esso.<\/p>\n\n

Le diverse fasi di uno sviluppo guidato da test<\/strong><\/h3>\n\n

Ci sono tre diverse fasi di TDD: Rosso, Verde e Refactor<\/p>\n\n

Seguire questo ordine di passaggi assicura di avere test per il codice che stai scrivendo, quindi devi scrivere i codici solo per quei test che stai facendo. <\/p>\n\n

Il palco rosso<\/strong><\/h3>\n\n

L’idea della fase rossa \u00e8 di far fallire il test, e anche la fase pi\u00f9 difficile perch\u00e9 si sviluppa deve scrivere il test senza codice. I nuovi sviluppatori devono trovarlo difficile perch\u00e9 sarebbero confusi su cosa testare senza avere il codice per esso. Ma \u00e8 una cosa abituale e con l’esperienza diventer\u00e0 liscia. Il primo test viene scritto senza scrivere codice e per dichiarare classe e metodo e il test avr\u00e0 un errore di compilazione. Il prossimo passo sarebbe correggere l’errore di compilazione ed eseguire il test per fallirlo. Questo provoca la bandiera rossa.<\/p>\n\n

La fase verde<\/strong><\/h3>\n\n

Dopo la fase rossa, il passo successivo sarebbe scrivere il codice. Questo codice dovr\u00e0 superare il primo test. Scrivere abbastanza codice per garantire che solo il primo test passi, \u00e8 un ostacolo che molti sviluppatori devono affrontare inizialmente. Perch\u00e9 nel prossimo test, dovrebbe fallire, seguito da un nuovo codice per superarli. <\/p>\n\n

\"\"<\/a><\/figure><\/div>\n\n

La fase del rifrattore<\/strong><\/h3>\n\n

Nelle prime due fasi, in cui il test deve prima fallire e poi passare, l’obiettivo era quello di far passare poi i test. Ma nella fase Refractor, dovranno essere considerati altri fattori come la qualit\u00e0 del codice, la manutenibilit\u00e0 del codice, la leggibilit\u00e0 del codice ecc. L’attenzione qui \u00e8 quindi su quegli aspetti, quindi i test unitari si concentreranno su quelli. Nella fase di refactoring, non devi preoccuparti dell’aspetto della funzionalit\u00e0 mancante, perch\u00e9 quando si verificano le modifiche al codice, i casi di test si conformeranno automaticamente anche alla parte di funzionalit\u00e0.<\/p>\n\n

TDD si adatta bene alla metodologia Agile<\/strong><\/h3>\n\n

\u00c8 abbastanza ovvio che i requisiti del progetto possono cambiare bene nella fase di sviluppo, quindi avere TDD in collaborazione con lo sviluppo Agile lo render\u00e0 sicuramente di successo e costruir\u00e0 progetti in linea con i requisiti del cliente. Con lo sviluppo guidato dai test, ottieni un feedback anticipato sul progetto su cui puoi lavorare facilmente. <\/p>\n\n

Aiuterebbe anche ad anticipare e ridurre i colli di bottiglia critici e garantire che il progetto proceda come previsto. I team di sviluppatori possono risparmiare molto tempo poich\u00e9 i test vengono creati molto prima nello sviluppo del progetto e non devono preoccuparsi di script di test estesi. <\/p>\n\n

Conclusione<\/strong><\/h3>\n\n

Il Test Driven Development \u00e8 una tecnica che richiede molto tempo, ma \u00e8 preziosa nel senso che ti aiuter\u00e0 a guidare il tuo progetto nella giusta direzione ottenendo un feedback corretto sul progetto e rilevando i bug. Tuttavia, \u00e8 un’opzione molto migliore rispetto ai test tradizionali in quanto richiede pi\u00f9 tempo e denaro. <\/p>\n\n

Link interessanti:<\/p>\n\n

Test Driven Development: cos’\u00e8 e cosa non \u00e8.<\/a><\/p>\n\n

Maggiori informazioni sullo sviluppo basato sui test<\/a><\/p>\n\n

Immagini: Canvas<\/p>\n\n

\"\"<\/figure><\/div>\n\n

L’autore: Sascha Thattil lavora presso Software-Developer-India.com che fa parte del gruppo YUHIRO. YUHIRO \u00e8 un’impresa tedesco-indiana che fornisce programmatori ad aziende IT, agenzie e dipartimenti IT.<\/p>\n