Anche gli ioni in una soluzione, in condizioni normali, si muovono per la sola agitazione termica e quindi anche il loro moto è browniano, all’insegna cioè della caoticità più radicale.

L’osmosi è quel fenomeno che consiste nel movimento di diffusione di due liquidi miscibili di diversa concentrazione, una membrana, semipermeabile o permeabile ai due mezzi. È un fenomeno molto importante e studiatissimo in biologia e perfino due metodi di conservazione dei cibi con cui tutti noi abbiamo a che fare ogni giorno sfruttano l’effetto osmotico: la salatura e la salamoia.

Anche in questo caso quindi con i test automatici ed il test driven development possiamo immaginare di porre una membrana semipermeabile tra due soluzioni di user story: quelle da fare e quelle fatte. Le storie così, nel loro moto comunque caotico, diffondono in maniera non reversibile verso lo stato di completamento e vengono messe al riparo da regressioni per sempre.

Sì sì, ho scritto per sempre.

Gli elettroni, se non è applicato un campo elettrico, si muovono per la sola agitazione termica e quindi il loro moto ubbidisce alle leggi della statistica e al principio di equipartizione dell’energia, secondo il cosiddetto moto browniano. Se applichiamo un campo elettrico il moto delle particelle resta caotico e non diventa affatto uniforme e rettilineo, ma la somma dei moti caotici presenta una deriva che costituisce per sé la corrente elettrica.

L’implementazione delle user story è soggetta, nostro malgrado, ad una certa caoticità di moto: scritta la storia il percorso alla completa realizzazione della feature descritta non è mai senza regressioni e, addirittura, per certi versi il destino di una user story non è mai certo, perchè la sua corretta implementazione può essere corrotta, dopo anche molti mesi, dall’integrazione nel nostro sistema di nuove storie.

I test automatici – come li conosciamo nel test driven development – danno a questo moto caotico un punto di soglia, di non ritorno. Una storia chiusa in un test non può più tornare indietro, perlomeno per gli aspetti caratterizzanti che ne abbiamo voluto testare. Come se lungo il conduttore in cui scorre una corrente elettrica avessimo installato un diodo, senza certo impedire agli elettroni di vagabondare in ogni direzione possibile all’interno del conduttore a livello locale, ma allo stesso tempo assicurandoci che ad un livello più globale la corrente scorra solo nella direzione voluta.

Le nostre user story, con l’applicazione rigorosa del test driven development, rimangono così naturalmente caotiche, ma soggette ad andare dalla scrittura all’implementazione certa senza regressioni impreviste.