Unit testing e database

Il problema di eseguire unit testing quando è coinvolto un database è piuttosto noto. Facendo alcune ricerche si trovano diversi approcci, ma nessuna soluzione definitiva. Nel nostro scenario abbiamo individuato una strategia interessante ed efficace (se abbiamo scoperto l'acqua calda e un approccio del genere era già noto e diffuso, chiedo venia, ci è sfuggito ), che parte da questi presupposti:

  • abbiamo un database di test dove, nella fase di sviluppo di una certa logica, abbiamo dei dati validi disponibili
  • abbiamo uno strato di accesso ai dati consistente, dove elementi di "definizione" delle estrazioni dati e di generazione automatica di codice ci danno la possibilità di disaccoppiarci dalla base dati reale, sia in termini di struttura che di dbms scelto

In questo contesto, ed avendo a disposizione dei nostri "driver" specifici del dbms scelto, abbiamo pensato di scriverne uno nuovo che "simulasse" il fatto di farci parlare con un Sql Server ma che nella realtà ci restituisse delle versioni "taroccate" degli oggetti SqlConnection, SqlCommand e SqlDataAdapter, passando attraverso le interfacce IDbConnection e IDbCommand e IDataAdapter. Questi componenti, in presenza di un database "reale", registrano ogni singolo accesso ai dati su un file, scrivendo il nome dell'interrogazione (o un sql parametrico), i parametri passati e un DataSet serializzato. Questo file resta così disponibile una volta che i test sono stati eseguiti con successo, e a partire da questo è facile, a fronte delle stesse interrogazioni, restituire i dati corretti per il test senza riprenderli dal database. Quindi, quando il test è pronto, potrà essere lanciato nei mesi a venire indipendentemente dal fatto che quel database di test contenga ancora dati validi, o addirittura dal fatto che esista ancora, il file di log sarà sufficiente per accendere le lucine verdi di NUnit e testare le nostre logiche di business  Al momento gestiamo solo letture di dati, ma con poco sforzo, e quando ci servirà, potremo gestire le classiche operazioni CRUD.

powered by IMHO 1.3

posted @ venerdì 8 settembre 2006 19.21

Print

Comments on this entry:

# re: Unit testing e database

Left by Lorenzo Barbieri at 08/09/2006 22.24
Gravatar
Ciao, per curiosità hai già provato la CTP5 di VSTS x DBPro?

# Re: Unit testing e database

Left by Roberto Vespa at 09/09/2006 12.46
Gravatar
Ciao, e grazie mille per la dritta su DBPro, non lo conoscevo e leggendo l'articolo trovato su http://msdn.microsoft.com/vstudio/default.aspx?pull=/library/en-us/dnvs05/html/TEDBPro.asp ho potuto verificare quanto sia interessante per molti aspetti al momento problematici in azienda. Peraltro, rispetto al nostro particolare scenario in cui i dati di test spesso sono spesso definiti da persone ed uffici scorrelati, e dove i dati "devono" essere proprio quelli per poter essere certi di testare correttamente una funzionalità, e quindi l'unico modo di avere dati attendibili spesso è andare a vedere cosa è stato messo su un qualche db in giro, un sistema in grado di "fotografare" in modo trasparente i dati si rivela utile. Dovrei provare a vedere come integrare questa strategia con la parte di data generation di DBPro, a quel punto saremmo a cavallo, anche se l'idea di riuscire a fare unit test senza dipendere dalla presenza di un database continua a piacermi :)

# Crystal awards, Crystal award

Left by CrystalAwards at 18/11/2011 2.24
Gravatar
ttp://holidaygiftideas.blogetery.com/2011/11/09/engraved-crystal-awards-plaques-and-trophies/
holidaygiftideas.blogetery.com/.../crystal-awar...


Your comment:



 (will not be displayed)


 
 
 
Please add 7 and 7 and type the answer here:
 

Live Comment Preview: