Mondi su mondi, sistemi di sistemi.

Test Driven Development: suoi vantaggi e un esempio

Il Test Driven Development (TDD) è una meto­dica di svi­luppo in cui il codice viene scritto dopo i test che ne veri­fi­cano la cor­ret­tezza. È un requi­sito fon­da­men­tale di sistemi come l’Extreme Programming (XP) o più in gene­rale di metodi di pro­gram­ma­zione defi­niti “agili”.

A mio parere il TDD può essere appli­cato con suc­cesso anche senza spo­sare in toto la filo­so­fia agile: con­sente di scri­vere codice migliore in ogni caso. E credo che sia una meto­dica desti­nata a rima­nere in uso ancora a lungo, anche dopo che il feno­meno XP (che rimane secondo me il più developer–friendly) e simili saranno passati.

Una degli aspetti più frut­tuosi del TDD è che con­sente di defi­nire molto pre­co­ce­mente i casi limite del soft­ware in svi­luppo, soprat­tutto quelli che sem­brano sem­pre troppo stu­pidi per essere testati; troppo stu­pidi adesso, cioè, per­ché poi, fra un mese o un anno tutte le assun­zioni tacite che ave­vamo ben chiare in testa saranno dimen­ti­cate e allora quei test, troppo stu­pidi per­ché vales­sero la pena di essere scritti, ci saranno di grande aiuto.

A chi avesse biso­gno di un esem­pio sem­plice e pra­tico su come fun­ziona il TDD, con­si­glio que­sto post di Brian Button.

Per proseguire

Commenti e trackback sono disabilitati.