Come per tutte i concetti o paradigmi o metodologie, nell'ambito informatico tutto è astratto e tutto può essere applicato a diversi concetti.
Affrontando soluzioni in D.D.D, emerge subito il concetto di Test-Driven, ma è contestualizzabile solo per il D.D.D. ? Secondo me il concetto è decisamente astratto...
Parafrasando l'esempio banale la realizzazione di una calcolatrice, sia l'analista che il programmatore, daranno per scontato che al primo avvio non si verifichino problemi, poi basta premere una lettera al posto di un numero... e puf ci becchiamo un eccezione...
Questo perchè ? Semplice Troppe volte ci si dimentica di testare tutto il nostro codice... no.
Questo avviene perchè non è chiaro lo scopo di quello che stiamo facendo.
E gli elementi "di base" che il più delle volte diamo per scontati non sono stati presi in considerazione.
Il paradigma del T-D è che si deve testare una funzionalità per volta e che il test deve essere ripetibile e che il test deve essere positivo prima di aver scritto il codice...
Ma davvero ?? Si Tornando alla nostra calcolatrice, se la pressione del bottone 1 deve scatenare
la scrittura del testo 1 nella casella di testo e popolare un buffer, già sappiamo che cosa non dovrà fare il bottone 1...
Interpretando quindi il T-D è utile sapere e implementare il codice affinche la pressione del bottone 1 corrisponda solo a quell'azione...
Detto così forse è anche troppo semplice, ma il concetto di base è questo.
Nessun commento:
Posta un commento