Qualche giorno fa UgiDotNet ha pubblicato un mio semplice intervento dal titolo “Isolare la dipendenza da DateTime.Now”.

L’articolo  vuole  essere  un  semplice  esempio  per  porre  l’attenzione  sull’importanza  di  creare,  ove necessario, un codice che sia  facilmente  testabile. Questa semplice necessità conduce all’adozione di una serie  di  provvedimenti  che  rendono  il  codice  più  flessibile,  modulare  e  aderente  a  principi  utili indipendentemente dalla tipologia di sviluppo adottata, quali SRP, KISS o SoC.

Nello specifico,  la creazione di una semplice astrazione, come in questo esempio porta numerosi vantaggi, tra i quali il disaccoppiamento del modulo dal tempo di sistema,  la semplicità richiesta per scrivere test ed eseguirli  in un ambiente congelato e  la possibilità di creare situazioni di anomalia (facendo restituire date fuori range, o in ordine inaspettato, simulando eventuali errori non facilmente riproducibili).

L’astrazione,  più  in  generale,  permette  di  isolare  facilmente  le  responsabilità  di  ciascun  componente, inducendo a pensare alle funzionalità offerte piuttosto che all’implementazione, e permette sia una facile estensione  in  uno  scenario  futuro  che,  soprattutto,  rende  possibile  creare  implementazioni  ad  hoc (solitamente via mocking framework) da utilizzare per  isolare completamente  il componente sotto test da dipendenze  incontrollabili  (DateTime.Now),  lente  (HugeDBDataAccess),    remote  (GoogleResponse)  o indisponibili (WonderfulServiceIWillWriteTomorrow).

Markino dice:

L’articolo propone alcuni scenari di testing in merito ad una possibile dipendenza da DateTime.Now. Sebbene la cosa potrebbe sembrare banale, in realtà con un esempio molto semplice l’articolo mostra chiaramente il problema della dipedenza dei test dall’ambiente in cui lo stesso è eseguito; dipendenze che inficiano i test e che ne fanno gridare l’inutilità...

L’articolo è dal mio punto di vista un’ottima presentazione per capire la filosofia con cui occorre approciare al testing e alle metodologie di testing. L’articolo mostra l’importanza di isolare le dipendenza saprattutto per rende il codice quanto più testabile.

Creare batterie di test richiede tempo, e anche il mantenimento degli stessi pensa molto sul bilancio di un progetto... quindi sebbene il testing dovrebbe essere un must, posso capire – in alcuni contesti - la scelta di non operare batteria di test approfondite, tuttavia è importante - ed è una cosa che cerco di non trascurare mai - la testabilità del  codice! Scrivere codice in primis testabile non è costoso ed è investimento per quando sceglieremo di creare test più approfonditi su tutta la linea di progetto o su un subset dello stesso.

Ringrazio sia Markino per la recensione che UgiDotNet per l’opportunità offertami.