Il Test Driver Development è una pratica di sviluppo ben integrata nei processi che seguono l’approccio Agile e la cultura DevOps. Io, per enfatizzare il concetto, preferisco usare il termine “Fondante” quando mi riferisco alla pratica TDD in DevOps. In questi ultimi anni ho avuto occasione di notare che l’uso del testing nello sviluppo dello scripting per management e automazione è scarso per non dire quasi assente. Per il linguaggio PowerShell non possiamo dare la colpa di questo agli strumenti che sono: disponibili, ben integrati e adeguatamente maturi. Con poco sforzo si può creare un ambiente di sviluppo confortevole usando Visual Studio Code e le estensioni ufficiali rilasciate da Microsoft a cui aggiungere steroidi pagando le fee richieste dal licensing dei PowerShell Pro Tools di Ironman Software. Le cause le troviamo, secondo la mia opinione, nella: storia, cultura e metodo di sviluppo delle automazioni basate sullo scripting. A differenza del software di prodotto, le tecniche di scripting prediligono un approccio pragmatico in cui i concetti di generalizzazione e riuso si acquisiscono in ambienti enterprise, raggiunta un’adeguata maturità di sviluppo attraverso vari scenari. Dopo un veloce startup pratico dell’ambiente di sviluppo, l’obiettivo di questa chiacchierata è commentare alcuni scenari pratici in cui il TDD espanda esponenzialmente le possibilità dello scripting prodotto unite ad un buon livello di affidabilità, comprimendo i tempi di sviluppo e collaudo. La mia speranza è che, terminata la chiacchierata, vi portiate a casa spunti per modi nuovi con cui sviluppare script PowerShell e una bibliografia che vi aiuti a navigare velocemente tra le fonti disponibili per approfondire l’uso del TDD in PowerShell.