Devo I Unit Test Data Access Layer? È una buona pratica e come si fa?

Question

Se sto avendo Data Access Layer (nHibernate) ad esempio una classe denominata UserProvider e una classe BusinessBlog UserBl, dovrei entrambi testare i loro metodi SaveUser o GetUserById, o qualsiasi altro metodo pubblico nel livello DA chiamato BL strato. È una ridondanza o una pratica comune da fare?

È comune al livello di unità di test DA o appartiene al dominio di test di integrazione? È meglio avere un database di test o creare dati di database durante il test?

Qualsiasi aiuto è apprezzato.

Answer 1

È buona norma scrivere un test di unità per ogni livello, anche il DAL.

Non penso che eseguire test sul db reale sia una buona idea, potresti rovinare dati importanti. Abbiamo usato per installare una copia del db per i test con i dati sufficienti per eseguire i test. Nel nostro progetto di test abbiamo avuto un file web.config speciale con impostazioni di test, come un ConnectionString per il nostro db di test.

Answer 2

Non c'è una risposta giusta a questo, dipende davvero. Alcune persone (ad esempio Roy Osherove) affermano che è necessario testare solo il codice con logica condizionale (istruzioni IF, ecc.), Che può includere o meno il DAL. Alcune persone (spesso quelle che fanno il TDD) diranno che dovresti testare tutto, incluso il DAL, e puntare a una copertura del 100% del codice.

Personalmente, lo provo solo se è logico, quindi finisco con alcuni metodi DAL testati e altri no. Il più delle volte finisci per controllare che il tuo BL chiami il tuo DAL, che ha qualche merito ma non lo ritengo necessario. Penso che abbia più senso avere test di integrazione che coprano l'app end-to-end, incluso il database, che copre cose come GetUserById.

In entrambi i casi, probabilmente lo sapete già, ma assicuratevi che i vostri test di unità non tocchino un vero database. (Nessun problema, ma questo è un test di integrazione, non un test di unità, poiché richiede molto più tempo e comporta un'impostazione complessa e deve essere eseguito separatamente).

Answer 3

Nella mia esperienza è stato utile testare ogni livello da solo. Integrandolo e testare di nuovo. Il test di integrazione normalmente non verifica tutti gli aspetti. A volte se il livello di accesso ai dati (non so nibernare) viene generato codice o sorta di codice generico sembra eccessivo. Ma ho visto più di una volta che il test sistematico paga.

È ridondanza? Secondo me non lo è.

È una pratica comune? Difficile da dire. Direi di no L'ho visto in alcuni progetti ma non in tutti i progetti in cui ho lavorato. Spesso dipendeva dal tempo/risorse e dalla mentalità del team/sviluppatore indipendente.

È meglio avere un database di test o creare dati di database durante il test? Questa è una domanda abbastanza diversa. Non si può rispondere facilmente Dipende dal tuo progetto. Creane una nuova è buona, ma a volte genera bug irreali (anche se bug). Dipende dal tuo progetto (sviluppo del prodotto o sviluppo proprietario). Di solito in uno sviluppo proprietario sul sito viene migrato un database da qualche parte. Quindi un secondo test è sicuramente necessario con i dati migrati. Ma questo è piuttosto a livello di test di sistema.

Answer 4

Unità testare il DAL vale come accennato se c'è una logica in là, ad esempio se si utilizza lo stesso StoredProc per inserto & aggiornamento sua pena sapere che funziona un inserto, la chiamata successiva, aggiorna il precedente e una selezionata restituisce e non una lista.Nel tuo caso il metodo SaveUser probabilmente inserisce la prima volta e successivamente gli aggiornamenti, è bello sapere che questo è ciò che viene fatto in fase di test unitario.

Se si utilizza un framework come iBatis o Hibernate in cui è possibile implementare typehandlers, è opportuno verificare che i gestori gestiscano i valori in modo accettabile per il DB sottostante.

Per quanto riguarda il test rispetto a un DB effettivo se si utilizza un framework come Spring, è possibile avvalersi delle classi di test dell'unità database supportate con il rollback automatico delle transazioni in modo da eseguire i test e successivamente il DB non viene modificato. Vedere here per informazioni. Altri probabilmente offrono un supporto simile.