Test unitari del DAL - per favore, critica

Question

Sono arrivato al punto del mio semplice progetto in cui sono pronto a testare l'unità DAL.

Fondamentalmente ho una classe chiamata FooDataAccess con diverse funzioni molto semplici, diciamo 3 di queste in questo modo:

int InsertFoo(string fooName)
void UpdateFoo(int fooID, string fooName)
void InsertFoosDepedency(int fooID, string someValue)

Quello che ho fatto è stato questo: inserire 4 script SQL nel mio progetto di unit test, l'ultimo come risorsa integrata.

1) Crea (Unit test) Script database, 2) Crea oggetti Script, 3) Inserisci valori tabella di ricerca e 4) Elimina tutti tranne valori tabella di ricerca

L'idea è che chiunque utilizzi per la prima volta il progetto dovrebbe eseguire manualmente gli script 1-3 manualmente come una configurazione singola. Quindi esegui lo script n. 4 all'avvio di ogni unit test ... (nelle piccole app, potresti persino eseguirle tutte a livello di test)

OK, finora tutto bene ...

Quindi ho impostato il mio database di unit test, come una lavagna vuota. Testare la prima funzione InsertFoo () è ovviamente molto semplice. Io chiamo la funzione, quindi solo Assert (ExecuteSQL (" select count (*) from foo ") > 1), Assert (ExecuteSQL (" select fooName da t_foo ") = previsto)), ecc.

Dove sono un po 'bloccato sono quelli che richiedono dipendenze, come la terza funzione nel mio esempio, o anche l'aggiornamento.

Avrebbe senso eliminare temporaneamente tutti i vincoli di chiave esterna per l'ambito del mio test? Altrimenti, per testare la funzione InsertFoosDepedency (int fooID, string someValue), dovrei prima eseguire un sql arbitrario (inserire manualmente un record nella tabella FOO e restituire il FooID) ...

OPPURE, dovrei fare solo quest'ultimo?

Qualsiasi feedback è molto apprezzato.

AGGIORNAMENTO: funziona in modo pulito con SQL inline per creare le persone a carico. Immagino che sto solo cercando commenti e amp; critica su questo metodo per unit testing DAL. Grazie ancora

Answer 1

Sembra abbastanza simile a quello che faccio. Distruggo tutti i dati nel database all'indirizzo inizio di ogni test e poi accumulo proprio quello che quel test richiede in quella fase di impostazione dei test. Quindi per UpdateFoo avrei

void update_existingKey_updatesValue() {
   String expected = "jeff";

   clearDatabase();
   // Note I would use dbUnit.
   executeSQL("insert into foo values (1, 'fred')");

   DAL subject = new DAL(...);
   subject.update(1, expected);  

   //Note I would use dbUnit.   
   String actual = executeSQL("select name from foo where id = 1"); 
   assert(expected, actual);
}

In Java utilizzo uno strumento chiamato dbUnit , i nomi dei tuoi metodi suggeriscono C #, quindi ti indicherò su dbUnit.Net tuttavia non l'ho mai usato. Ciò fornisce un metodo migliore (IMO comunque) per popolare il database e verificare il contenuto del database.

Answer 2

Direi che non non è mai andato in giro con il tuo schema per motivi di test. Se non riesci a rimetterlo o il tuo codice per ripristinarlo fallisce, ti ritroverai molto rapidamente in un casino.

Puoi usare Mock Objects ?

Se no, penso che tutto ciò che puoi fare sia impostare i pre-req del database per ogni test.

È possibile prendere in considerazione una classe separata per ogni test e utilizzare i metodi Setup e Teardown per riportare il database nelle condizioni giuste per i test.

Oppure devi solo fare la tua configurazione specifica del test nel metodo Test (e potresti usare Teardown per svuotare il DB in seguito).