Il test double, è una tecnica utilissima per aumentare la "testabilità" del codice, ma come fare per usare questa tecnica in maniera efficiente. Un pattern che uso costantemente è quello dell'override per le istanze singleton. Faccio un esempio. Se in un progetto ho un DAL molto standard che usa un Dao per tabella (un table module) gli oggetti Dao sono solitamente senza stato, per questa ragione utilizzo il pattern Registry in cui tengo le istanze singleton dei miei Dao. (Questo quando non posso usare Nhibernate :P). In sostanza ovunque il codice necessiti di un dao non fa altro che chiamare ad esempio Registry.CustomerDao, dove Registry è una classe statica. Questa struttura è forse anche troppo semplice, ma per progetti molto ridotti con accesso limitato a 2 o 3 tabelle può anche risultare sufficiente senza scomodare contenitori di inversione di controllo e vari. L'interessante è vedere come viene implementato l'accesso ai Dao.
private static IDdtDao ddtDao;
private static IDdtDao DefaultDdtDao {
get { return ddtDao ?? (ddtDao = new ConcreteDdtDao()); }
}
public static IDdtDao DdtDao {
get { return overridingDdtDao ?? DefaultDdtDao; }
}
private static IDdtDao overridingDdtDao;
public static IDisposable OverrideDdtDao(IDdtDao overrideDdtDao) {
overridingDdtDao = overrideDdtDao;
return new DisposableAction(delegate() {
overridingDdtDao = null;
});
}
Prima di tutto ogni Dao ha la sua interfaccia (per fare test double), il registry ha una proprietà chiamata DefaultDao che utilizza il LazyInitialization, ma la cosa interessante è che è presente una ulteriore istanza di Dao chiamata overridingDdtDao. L'utilizzatore accede all'istanza tramite la proprietà DdtDao che ritorna l'overridingDao se quest'ultimo è diverso da null. La funzione OverrideDdtDao() serve appunto ad impostare l'overridingDao e restituisce una DisposableAction, il cui unico scopo è riportare il valore di overridingDdtDao a null. Tutto questo codice permette di fare un test di questo tipo.
IDdtDao dao = mMockery.CreateMock<IDdtDao>();
using (mMockery.Record()) {
…
}
using (Registry.OverrideDdtDao(dao))) {
//in questo scope ogni oggetto che prende il DdtDao dal registry ottiene invece il mock.
}
E il gioco è fatto, in questo modo io posso creare degli scope con la keyword using all'interno dei quali gli oggetti del registry sono rimpiazzati da TestDouble. Il SUT a questo punto ignora tutta questa struttura e chiamando Registry.DdtDao durante il test lavora con un TestDouble :P.
Alk.