In questi giorni sto facendo largo uso di TDD per implementare un sistema discretamente complesso di parsing/trasformazione di informazioni da un formato ad un altro: db –> Object Model –> DTO –> Flat text File.
Un po’ di considerazioni live durante l’esperienza:
Produttività
Dobbiamo prima definire cosa intendiamo per produttività, se pensiamo a meri tempi di scrittura del codice, la sentenza è “bassa produttività”, se invece, come doveroso, ci mettiamo anche qualità del prodotto finito, le cose cambiano un filino, decisamente alta.
Design Emergente
Decisamente si, non è che sia molto da fare, devo ammettere che funziona ;-). Probabilmente l’avrei disegnato così anche senza TDD ma è indubbio che l’uso di questa metodologia mi ha obbligato (in senso positivo) a disegnarlo così pena, ad esempio, l’impossibilità di testarlo.
E’ stato inevitabile produrre molto piccoli e molto tanti componenti.
Confidenza
Questo, secondo me, è l’aspetto più importante: la suite di test che vi trovate in mano vi da una notevole confidenza con il vostro codice.
Strumenti
All’inizio si ha l’impressione che un tool di refactoring serio sia indispensabile, ma alla fine sto cambiando idea. Causa “pasticcio” con i package sulla mia macchina l’installazione di Visual Studio è un po’ troppo traballante ormai e non c’è mezzo di installare nulla ergo i tool di JetBrains non vanno più su…questo però mi ha portato a constatatre che, dopo un momento inizale di sconforto perchè si ha la sensazione di perdere in produttività, forse non sono proprio un vantaggio. L’assenza di un tool che si limita a velocizzare alcuni passaggi porta un vantaggio secondo me notevole:
  • vi da il tempo di pensare a quello che state facendo;
  • vi da il tempo di ragionare sul nome che avete scelto per un membro;
  • vi da il tempo di ragionare sull’interazione che state testando tra due componenti che ancora non esistono;
Quello che voglio dire è che non è detto che estremizzare la produttività sia sempre un bene.
Vantaggi evidenti: refacoring
Il refactoring diventa un vero e proprio esercizio di stile molto semplice perchè la suite di test vi “para il c*lo” (francesismo e licenza poetica) e vi da quella sicurezza che fa decisamente bene.
Vantaggi evidenti: “il test prima”
Lo scrivere i test prima della funzionalità aiuta a non farsi influenzare nella scrittura del test, se il test lo scriviamo dopo, rischiamo di essere influenzati da come abbiamo implementato l’algoritmo mentre in questo caso è decisamente difficile. E’ vero che se c’è disciplina è abbastanza facile non farsi influenzare da noi stessi ma è anche vero che se possiamo fare uno sforzo in meno… tanto di guadagnato.
Complesso?
Secondo me abbastanza, nel senso che comunque ci vuole una discreta esperienza/disciplina per affrontare il tutto:
  • Scivolare durante lo sviluppo e tornare alle vecchie abitudini, come ad esempio implementare la feature prima di aver scritto il test, è abbastanza facile e ci vuole molta disciplina;
  • Trattnersi dallo scrivere test che testano casi che non fanno parte dei requisiti e quindi non sovraingenierizzare è sempre difficile… ;-)
.m