Unit test di servizi di dominio su un database reale

Question

Mi chiedevo quali approcci potrebbero avere gli altri per testare i servizi di dominio su un database? Ho già una serie di repository finti che sono in grado di utilizzare nei servizi di dominio per testare i servizi di dominio stessi. Parte della costruzione di questi repository finti è che creano aggregati di esempio ed entità associate e li convalidano in base alle stesse regole commerciali che verrebbero altrimenti utilizzate nel modello. Ciò fornisce anche un mezzo piacevole e semplice per rilevare potenziali punti di impatto all'interno delle entità stesse, nel caso in cui le loro interfacce cambino.

Il problema principale che riscontro con i test in tempo reale dei miei repository supportati da SQL è la coerenza del database. Ad esempio, una volta eseguito un test, " create " aspetti sono già stati gestiti. La loro esecuzione di nuovo causerebbe ovviamente errori, poiché il database non è più pulito. Stavo pensando di creare un database con mirroring utilizzato solo per questo tipo di test. Sarebbe minimo, contenente struttura, programmabilità, vincoli, ecc. Fornirei anche un set minimo di dati per alcuni test stabiliti. La mia linea di pensiero è che potrei avere una procedura memorizzata che potrei chiamare per ripristinare il database su "incontaminato" stato con i dati di base prima dell'inizio dell'esecuzione del test.

Anche se questo non è così importante su una macchina sviluppatore dopo che la funzionalità è stata inizialmente verificata, sto esaminando di più l'importanza di eseguire questi test come parte della build notturna; in modo che in caso di fallimento di un test, la build potrebbe essere trattenuta per non sporcare l'ambiente di distribuzione di destinazione (in particolare in questo caso, sarebbe l'ambiente utilizzato dal team di test).

Non penso necessariamente che la piattaforma sia importante, ma nel caso qualcuno abbia problemi specifici di implementazione, il mio ambiente è simile al seguente:

Windows 7 (Sviluppo) / Windows Server 2008 R2 (Server) Visual Studio 2008 Team Edition (C #) Microsoft SQL Server 2008 Standard (Sviluppo / Server)

Sto usando Team Build per eseguire le mie build, ma molto probabilmente non è un fattore che rientra nella portata della domanda.

Answer 1

  

Ad esempio, una volta eseguito un test, " create " aspetti sono già stati gestiti. La loro esecuzione di nuovo causerebbe ovviamente errori, poiché il database non è più pulito.

Forse potresti rendere transazionali i tuoi test unitari. Esegui i test, esegui il rollback e il database rimane invariato.

Spring ha classi di test di unità transazionali che lo rendono facile da fare. Hai solo bisogno di un gestore delle transazioni.

Answer 2

Puoi utilizzare SQL Server Express (I ' l'ho fatto con il 2005, ma non ho provato con il 2008) per impostare "deck di test" database che sono memorizzati come file. Questi possono essere archiviati per il controllo del codice sorgente, quindi le classi helper di test possono (a) copiarli in cartelle temporanee, (b) abilitarli alla scrittura e (c) connettersi ad essi. Per ripristinare lo stato originale, eliminare la copia temporanea e ripetere a-c.

Questo è un dolore enorme. Se puoi cavartela con le transazioni (come suggeriva Duffymo). I punti deboli con le transazioni sono le transazioni nidificate e quelle distribuite - fai attenzione a quelle nel tuo codice.

Answer 3

Puoi creare un gruppo di data factory nel codice di test che inizialmente vengono eseguiti all'avvio della tua esecuzione di test. Quindi utilizzare il metodo di rollback della transazione per mantenerlo intatto. Per semplificare, sottoclassare tutte le classi di test e inserire l'accessorio di transazione e il codice di rollback. Il codice di rollback può essere impostato per essere eseguito automaticamente al completamento di ogni metodo di prova.

Answer 4

se in realtà stai eseguendo unit test per il tuo repository che stanno colpendo un database, NON STAI EFFETTUANDO UNITÀ DI PROVA. Potrebbe essere un test utile ma non è un test unitario. Questo è un test di integrazione. Se vuoi farlo e chiamarlo test di integrazione, allora va benissimo. Tuttavia, se si seguono buoni principi di progettazione nei propri repository, non è necessario testare MAI il database, MAI, nei test unitari.

Molto semplicemente, il test dell'unità del repository NON consiste nel testare quali ampi effetti si verificano nel database in base all'input nel repository; è per confermare che l'input nel repository comporta una chiamata a un collaboratore con tale e tale insieme di valori.

Vedete, il repository, come il resto del codice, dovrebbe seguire il principio di ripetibilità singolo. Fondamentalmente il tuo repository ha UNA e SOLO UNA reposibilità e ciò significa mediare le preoccupazioni dell'API del modello di dominio sul livello tecnologico di accesso ai dati sottostante (di solito ADO.Net ma potrebbe essere Entity Framework o L2S o altro). Seguendo l'esempio delle chiamate ADO.Net, il repository non dovrebbe assumersi la responsabilità di essere una factory per il livello dati e dovrebbe invece dipendere da un collaboratore dalle interfacce dati ADO.Net (in particolare IDbConnection / IDbCommand / IDbParameter eccetera). Basta prendere un IDbConnection come parametro del costruttore e chiamarlo un giorno. Ciò significa che è possibile scrivere test unit repository contro le interfacce e fornire simulazioni (o falsi o stub o qualsiasi cosa sia necessaria) e confermare che vengono eseguiti i metodi richiesti, in ordine, con gli input previsti. Vai a controllare il mio blog MS su questo argomento esatto - > http: // blogs.msdn.com/b/schlepticons/archive/2010/07/20/unit-testing-repositories-a-rebuttal.aspx

Spero che questo ti aiuti a fare un errore nel test e nella progettazione in futuro.

BTW: se si desidera testare l'unità nel database, è possibile. Usa i test del database di Visual Studio. Ha costruito INTO vs ed è in circolazione dal VS2005. Questa non è una novità. Ma devo metterti in guardia, devono essere test unitari completamente SEPERATI.

Answer 5

Se il tuo codice è abbastanza indipendente dal database, l'utilizzo di un database in memoria come SQLite per test unitari (non test di integrazione) ti darà i vantaggi di velocità e facilità (le tue configurazioni di test inizializzano il db).