Determinazione del modo migliore (o modi) di aggiungere test unitari a un progetto di grandi dimensioni che faccia buon uso delle stored procedure

Lavoriamo su una piattaforma di casinò / giochi / portafoglio / lotteria abbastanza grande. È un'applicazione chiavi in mano attualmente utilizzata da 4 client e presto sarà molto di più. Ho creato alcuni punti elenco relativi all'architettura sottostante:

• ~ 130K LOC in solo codice C #
• oltre 500 processi memorizzati, in uno dei 5 database utilizzati dal nostro sistema - poiché il nostro codice viene utilizzato in ambienti regolamentati, il codice sorgente è "bloccato" per alcuni client fino a quando non viene esaminato da un'agenzia esterna (molto costosa), quindi apportare modifiche tramite stored proc è un buon bilanciamento per mantenere felici sia i regolatori che i clienti. Gli altri database non sono vicini alla complessità del database "principale".
• Codice dell'applicazione C #, distribuito in Windows Form, Xamarin Android, servizi Windows, app Web, libreria CLR SQL, librerie di classi e progetti di test unitari
• Utilizza EF6 per il livello dati, alcuni ad-hoc, alcuni processi memorizzati

Mentre abbiamo alcuni test unitari in atto, è principalmente per roba relativa alle infrastrutture. Non ci sono molti test che testano le funzionalità aziendali. L'altro problema è che molti lavori pesanti vengono eseguiti nelle procedure memorizzate. È giunto il momento di aggiungere alcuni test unitari prima di iniziare a rifattorizzare parte del codice, per evitare regressioni. Quello che sto cercando è un elenco dei diversi modi per farlo. Questo è quello che ho inventato finora:

• Abbiamo un'istanza di SQL Server "Test" che potremmo impostare per cancellare e ripopolare i dati all'avvio di ciascun test.
  • Pro
    • Lo script di dati di cancellazione / ricarica può essere facilmente modificato quando si aggiungono nuovi test
  • Contro
    • Lo script clear / reload potrebbe diventare enorme
    • I test potrebbero essere lenti a causa della cancellazione / ricarica dei dati su ogni prova di test
• Potremmo usare Moq per deridere il contesto dei dati EF6 come ho letto su SO
  • Pro
    • Il test sarebbe veloce dato che i dati verrebbero dal codice C # e saranno compilati
  • Contro
    • L'aggiunta di dati di test in C # richiederebbe sempre
• Utilizzare il metodo più semplice per testare i proc # C che non utilizzano stored procedure e utilizzare il prodotto di test SQL di Redgate per testare le procedure SQL da solo
  • Pro
    • Incerto. Pur possedendo la suite di sviluppo dei prodotti Redgate, non abbiamo mai utilizzato il test SQL.
  • Contro
    • Non è una vera prova del funzionamento interno dei procs a mio parere
• Crea un nuovo override del contesto di dati EF che carica forzatamente i database sul server QA, crea un nuovo SqlTransaction sulla connessione e, quando viene eliminato, chiama Rollback per eliminare eventuali modifiche apportate
  • Pro
    • Non richiede molte modifiche a molti interni del codice esistente o refactoring
  • Contro
    • Richiede che noi refactoring un gruppo di codice per prendere una connessione al database piuttosto che consentirne la creazione, ad es. creare un IOC per ottenere la connessione al database

Il piano che ho è quello di fare un paio di buoni test scritti, e se un sacco di refactoring non è nelle carte, il nostro addetto al controllo qualità impara a programmare scrivendo dei test basati sugli esempi fatti durante l'impostazione.

Come dovrei gestire l'aggiunta di test di unità a un progetto di grandi dimensioni? Come dovrei gestire le procedure di test che chiamano stored procedure in un database? Quello che mi piacerebbe sapere è il modo migliore per eseguire lo shim unit test senza un sacco di refactoring. Rifattorizzare questo codice per disaccoppiare il livello dati, per alcuni punti, non sarebbe difficile, ma in altri punti sarebbe difficile da fare, quindi il metodo con la minore quantità di attrito sarebbe il migliore.