Unità regole di test

Question

La mia domanda può sembrare davvero stupida per alcuni di voi, ma devo chiedere .. scusa ..

io non capisco principi di test di unità .. Come si può testare le classi del vostro business classi o livello di accesso ai dati senza modificare il database? Spiego, ho una funzionalità che aggiorna un campo in un database .. Niente di così sorprendente .. La classe del livello Business è istanziata e il metodo BLL.Update() fa alcuni controlli e infine istanzia una classe DAL che lancia uno storage procedura nel database con i parametri corretti.

sue opere, ma la mia domanda è ..

Per fare unit test che verificano la classe DALayer devo incidere il database nelle prove! Per testare ad esempio se il valore 5 è passato bene al DataBase devo farlo e il campo del database sarà 5 dopo il test!

Quindi so normalmente il sistema non è influenzato dai test in modo che io non capisco come si può fare i test senza senza eseguire i metodi ..

Tx per le risposte e scusate il mio povero inglese ..

Answer 1

Dividerò la tua domanda in diverse sottofunzioni perché è difficile rispondere insieme.

Unit Testing x Integrazione test

Quando si scrive unità semplice test di unità che si sta testando. Ciò significa che stai testando un singolo percorso di esecuzione nel metodo testato. È necessario evitare di testare le sue dipendenze come database menzionato. Di solito si scrive un semplice test unitario per ogni percorso di esecuzione in modo da avere una buona copertura del codice dai test.

Quando si scrive test di integrazione, si stanno testando tutti i livelli per verificare se l'integrazione e la configurazione funzionano. Di solito non si scrive test di integrazione per ogni percorso di esecuzione perché ci sono molte combinazioni su tutti i livelli.

classi di business Testing - Test delle unità di

È necessario testare le vostre classi di business senza la dipendenza a DAL e DB. Per farlo devi progettare la tua classe BL in modo che quelle dipendenze vengano iniettate dall'esterno. Per prima cosa è necessario definire una classe astratta o un'interfaccia per DAL e passare quell'interfaccia DAL come parametro al costruttore (un altro modo è esporre la proprietà impostabile sulla classe BL). Quando testate la vostra classe BL, userete un'altra implementazione dell'interfaccia DAL che non dipende dal DB. Esistono modelli di test ben noti Mock, Stub e Fake che definiscono come creare e utilizzare tali implementazioni fittizie. Il mocking è supportato anche da molti framework di test.

test di accesso ai dati strato - test di integrazione

È necessario testare la vostra DAL contro il Real DB. Preparerai il DB di test con il set di dati di test e scriverete i test per lavorare con quei dati.Ogni test verrà eseguito nella propria transazione, che verrà ripristinato alla fine in modo da non modificare il set di dati iniziale.

Con i migliori saluti, Ladislav

Answer 2

Per lo scenario che descrivi in ​​termini di interazione db, è utile il mocking. Se ne avete la possibilità, date un'occhiata a Rhino Mocks

Answer 3

Utilizzate Inversion of Control insieme a una struttura di derisione, per es. Rhino Mock come qualcuno ha già menzionato

Answer 4

Se non ricorrono a beffardo e l'utilizzo effettivo DB nei test allora sarà test di integrazione in termini profani e non è più una prova di unità. Ho lavorato a un progetto in cui un sql .mdf dedicato era nel controllo del codice sorgente che è stato collegato al server del database utilizzando NUnit nella parte [Setup] di [SetupFixture], simile a Stilista in [TearDown]. Questo è stato fatto ogni volta che sono stati eseguiti i test NUnit e potrebbe richiedere molto tempo, a seconda del codice SQL che hai e della dimensione dei dati può peggiorare.

Ora il catch è il sovraccarico di manutenzione, è possibile modificare lo scehma del database durante il ciclo di sprint e al rilascio, lo script del DB di modifica deve essere eseguito su tutti i database utilizzati nel proprio sviluppo e test incluso quello utilizzato per i test di integrazione come menzionato sopra. Non solo, i nuovi dati di test (come qualcuno menzionato sopra) devono essere popoulati per nuove tabelle/colonne create e allo stesso modo, potrebbe essere necessario pulire anche i dati esistenti a causa di modifiche ai requisiti o correzioni di errori.

Questo sembra essere un compito in sé e qualcuno competente nel team può assumere la proprietà o se il tempo lo consente è possibile integrare l'esecuzione di script di cambiamento come parte di Continuous Integration se ne è già stato implementato uno. Eppure l'aggiunta e la pulizia dei dati di test devono essere risolti manualmente.