La legge implicita del test unitario

27 September, 2008 (09:49) | agile, programming, test

Uno degli ultimi post dal blog di Roy Osherove ha scatenato parecchie reazioni nella blogosfera. Roy sostiene, fra le altre cose (vi consiglio di leggere il post originale e il suo seguito), che per permettere la scrittura di test unitari sono stati introdotti talmente tanti concetti

mocks, stubs, dependency injection, IoC containers, Extract & override technique, Record\Replay, AAA and more

da rendere troppo ripida la curva d’apprendimento per un programmatore inesperto. Questa secondo Roy sarebbe uno dei freni alla diffusione dei test unitari (e a seguire del TDD) come pratica di programmazione

Concordo sul fatto che nella maggior parte dei casi tutta la sovrastruttura messa in campo per abilitare/facilitare la scrittura di test unitari sia sostanzialmente un bad smell. E’ inutile proporre il test unitario come strumento di design dicendo che il “codice facilmente testabile è anche dotato di buone proprietà quali basso accoppiamento, alta coesione, ecc…” quando poi vengono proposti framework e strategie per facilitare il test unitario di codice difficilmente testabile :-) I framework citati sono nati per permettere ai programmatori di testare in maniera automatica

  • codice legacy
  • codice che “vive” hai confini del proprio sistema e che “parla” con altri sistemi (ex: DBMS, file system, network, ecc…)
  • codice che usa librerie proprietarie
  • ecc…

Nel resto dei casi sarebbe meglio rifattorizzare il codice per renderlo facilmente testabile e fargli acquisire le buone proprietà di cui sopra, da qui la legge implicita del test unitario: “Se scrivere un test unitario per un pezzo di codice è troppo difficile, non riscrivere il test, riscrivi il codice”

Comments

Comment from .MOz
Date: September 29, 2008, 8:45 am

Sono perfettamente d’accordo… è esattamente in questo senso che il test unitario è un buono strumento di progettazione: se non si riesce a testare una classe come si vorrebbe, probabilmente la classe ha qualcosa che non va a livello di design.

E’ vero anche che non è sufficiente avere una classe testabile per avere una “buona” classe: in questo senso concordo con Roy, i principi SOLID sono fondamentali e sarebbe bene che chi scrive (test o codice) li avesse sempre in mente, sia in modo conscio sia in modo inconscio (i programmatori esperti sentono la puzza da molto più lontano). Imparare la progettazione attraverso il solo unit testing è troppo lungo, faticoso e soggetto a errori.

La parte difficile del riscrivere il codice è invece particolarmente evidente nei sistemi legacy, dove la domanda fondamentale è “sto rompendo qualcos’altro?” Il vero problema in questi casi è infatti garantire il precedente funzionamento del sistema. E questo è il motivo per cui prima di cambiare si scrivono (si dovrebbero scrivere) i test. Solo che in questi casi è difficile scrivere i test. Per fortuna possiamo andarci a leggere il Weathers… E usare uno dei famosi framework ;-)

Write a comment