Penso che più tempo sia stato sprecato a discutere su cosa sia un'unità rispetto a quale sia un test di integrazione rispetto al valore aggiunto.
Non mi interessa.
Lasciatemelo dire in un altro modo: se lo stavo testando, vedrei due modi per farlo: rimuovere il database restituendo zero righe o connettersi effettivamente a un database che non ha dati per la selezione. Probabilmente inizierei a testare con qualsiasi cosa fosse più facile da fare e più semplice da implementare - se fosse abbastanza veloce da consentirmi di ottenere un feedback significativo. Poi considererei l'altro se ne avessi bisogno per correre più veloce o pensassi che ci sarebbe stato qualche vantaggio.
Ad esempio, probabilmente mi collegherò al DB di test effettivo al mio lavoro. Ma se il software avesse bisogno di lavorare con molti database diversi - Oracle, PostGres, MySQL, SQL server e DB, o se il DB di test al lavoro fosse inattivo per 'refreshes' molto, probabilmente scriverei 'pure/unit' test che esisteva totalmente isolato.
Nella mia vecchiaia, preferisco usare più spesso il termine "rivolto allo sviluppatore" o "rivolto al cliente" e fare il tipo di test più sensato. Trovo che usare termini come "unità" in modo estensivo, e poi ottenere una definizione - weenie a riguardo porta le persone a fare cose come prendere in giro il filesystem o deridere getter e setter - attività che trovo non utile.
Credo fermamente; Ho presentato prima di google su di esso.
http://www.google.com/url?sa=t&source=web&oi=video_result&ct=res&cd=1&url=http%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DPHtEkkKXSiY&ei=9-wKSobjEpKANvHT_MEB&rct=j&q=heusser+GTAC+2007&usg=AFQjCNHOgFzsoVss50Qku1p011J4-UjhgQ
buona fortuna! Fateci sapere come va!
fonte
2009-05-13 15:53:50
Pensare al "test unitario" nel senso di "sistema chiuso" è molto utile per differenziarlo dal "test di integrazione". – hurikhan77