Metti alla prova i tuoi SQL / HQL / Criteri?

1. Verifica sempre il tuo DAO o il tuo repository per il caso più semplice, solo per assicurarti di aver collegato tutto correttamente
2. Verifica normalmente i tuoi metodi DAO o Repository se esegue qualsiasi logica oltre a invocare l'API di ibernazione
3. Fai il minimo lavoro possibile per testare il livello di persistenza!

È possibile impiegare troppo tempo ed energia per testare un livello di persistenza e ricavarne pochissimo valore se si è troppo preoccupati per la perfetta configurazione del test, questo è in qualche modo mitigato se la vostra azienda si standardizza al metodo di test in modo tale che è facile da configurare una seconda o terza volta. Ma in generale puoi testare gli aspetti più importanti semplicemente usando SQL nei metodi di setup e teardown, usando anche asserzioni sql personalizzate.

Non ho mai provato DbUnit . Quello che faccio con nHibernate è la creazione di test suite che creano il database & dati al momento dell'impostazione (utilizzando sia SchemaExport sia inserimenti batch), quindi esegui test che controllano sia le entità che le query.

Uso database di sviluppo locale come SQL Server Express di Oracle Express Edition a seconda del progetto.

In un progetto molto grande di cui facevo parte, abbiamo utilizzato Rollback technique . Ogni test stava creando una transazione che è stata ripristinata alla fine. Questo è descritto qui .

Ma c'è un modo migliore di testare. Ieri ho letto un libro chiamato nHibernate 3.0 Cookbook da Jason Dentler in cui l'autore propone un metodo chiamato Test rapido con SQLite in -memoria database .

Non l'ho ancora provato, ma quella ricetta è completamente dettagliata e sembra promettente.

Sono sicuro che puoi scaricare il codice di esempio da qualche parte (non è stato in grado di trovarlo rapidamente), ma consiglio vivamente di acquistare il libro. Contiene altre tecniche di test come Fluent nHibernate Persistance Tester e Ghostbusters test .

Questa tecnica è spiegata anche in questo post sul blog .

Si Una funzione o qualsiasi alterazione dei dati può essere testata come qualsiasi altra lingua. Se riesci a testare l'aggiunta, l'eliminazione o l'aggiornamento dei valori in un array, funziona con una tabella diversa?

Se sto cercando di ottimizzare un'istruzione select, verrà testata sullo stesso dataset prima e dopo per due motivi: 1) deve restituire gli stessi dati 2) è il modo migliore per vedere se è più veloce ( confrontare le mele con le mele). Poiché il database fa tante cose dietro le quinte in cui si ha meno controllo (statistiche, frammentazione dell'indice, ottimizzazione delle query e memorizzazione nella cache), occorre fare attenzione quando si confrontano le prestazioni dell'ambiente o dell'insieme di dati con il successivo. Quindi puoi modificare i criteri o anche il database di test (altra azienda o altro backup / versione).

Questo è il modo in cui ho configurato i test di integrazione di NHibernate:

Per prima cosa creo un db nuovo prima di eseguire i miei test di integrazione. Ogni query e mappatura delle entità viene testata nella sua stessa fixture.

Eseguo ogni test in una transazione che viene ripristinata al completamento. Ogni test è responsabile della configurazione dei dati di test.

Questo approccio ha funzionato abbastanza bene per me, specialmente per testare le query e se restituiscono o meno risultati attesi.

Nel mio progetto corrente ho tentato inizialmente di testare il mio SQL verificando che corrispondesse ai valori attesi. Poi ho apportato una modifica alla mia generazione SQL che ha causato la modifica di ogni query (in un modo che non ha fatto alcuna differenza per tutti tranne il caso di test più recente), causando così il fallimento di tutti i miei test.

Ugh ...

Ora, eseguo un test su un database SQLite in memoria e il framework che utilizzo (SQLalchemy) si occupa di gestire le differenze tra il database di destinazione. Incapsulo il processo di acquisizione di un database in modo che possa passare i miei test per eseguire occasionalmente il mio server di database (Firebird), che richiede molto più tempo per essere eseguito.