Test di integrazione della logica SQL

Se un test unitario si rompe, di solito sai esattamente cosa è andato storto; quando un test di integrazione si rompe, è un suggerimento che un pezzo del tuo processo abbia qualcosa di sbagliato in esso. Se sei a tuo agio con questo e il tuo SP non è incredibilmente complesso, i test di integrazione di C # dovrebbero andare bene.

Alcune cose da considerare:

Utilizza un framework di test unitario. Chiamarli "C # Scripts" mi chiedo se stai facendo questi test senza un adeguato framework di test unitario.

Esaminare il rollback dei risultati di eventuali modifiche al database dopo l'esecuzione del test. Ecco un esempio precedente ma dovrebbe funzionare in qualsiasi runner di test

In parole povere, sembra un test unitario. I tuoi "script C #" sono le unità di pass / fallimento.

Is there any practice better than this one to validate SQL based code ?

Non dovresti preoccuparti di convalidare il codice SQL reale. Tutto ciò che veramente dovrebbe interessare è la validità dei dati e il risultato. Dovresti disaccoppiare i tuoi test unitari dall'effettivo meccanismo sottostante (un RDBMS in questo caso), in modo che il test dell'unità sia intercambiabile se l'origine dati sottostante diventa diversa o anche di un tipo diverso (pensa: file flat, richiesta di servizio, API chiama, ecc.).

Un esempio

Una casa automobilistica non dovrebbe preoccuparsi delle proprietà molecolari e dei test del metallo che usano per le loro auto. Dovrebbero preoccuparsi dei numeri e della decelerazione durante un test d'impatto della macchina. Pensa in grande.

Quindi la domanda migliore qui non dovrebbe essere "come faccio a testare la mia logica SQL", ma dovrebbe essere "come faccio a testare e convalidare la mia logica e i miei dati".