In "UnitTest e Code Coverage, parliamone" ho dato il mio personale punto di vista sul testing, in parte discusso e in parte condiviso che credo si possa riassumere nei punti:
-
Unit Test sul sistema nella sua integrità preferendolo allo Unit Test subito per ogni singola coponente isolata dal contesto di utilizzo.
-
Il code coverage non è garanzia di buon codice e/o di assenza di bug, ho infatti mostrato che si può avere un code coverage alto senza testare alcun caso limite.
Perchè questo post quindi? Per non lasciare indefinito\vago quanto detto in "in genere tendo a preferire i test verticali di tutto l'impianto integrato fatta eccezione per componenti molto particolari per le quali giudico opportuno testare isolatamente". Quali sono le regole per quali giudico una componete particolare e "degna" di Unit Test specifico?
Considero progetti particolari - dei quali quindi voglio creare il progetto di testing - tutte quelle librerie che voglio facciamo parte di un framework a supporto di altri progetti o librerie - che nascono come componenti riusabili - che fanno da connettore verso particolari risorse, particolari librerie o particolari sistemi.
Preferisco testare unitamente al sistema (come nell'esempio di Class4) tutti i provider/mapper nati escusivamente per lo specifico progetto/soluzione (data provider, data mapper e compagnia cantante). Ovviamente per tali test includo anche l'interazione diretta con il database, sebbene per ques'ultima parte NON ci sono/non vedo strumenti che facilitano i test (database virtuali etc). Preferisco per tali componenti creare unit test specifici solo in fase di refactoring o dopo solo l'individuzione di bug.
Cosa ne penso del TDD? Ottima tecnica per approciare allo sviluppo di librerie di cui voglio investire nell'implementazione di test.
oO0( that's my 2 cents)
posted @ sabato 7 giugno 2008 18:41