Un framework di simulazione è utile se sto testando un repository / database? [duplicare]

Ci sono diversi lati del test unitario:

1. Il test unitario ha lo scopo di darti la certezza che un componente funziona come dovrebbe e che le future modifiche non infrangeranno nessuna delle funzionalità attuali.
2. I test unitari dovrebbero essere abbastanza veloci da poter essere eseguiti spesso senza che ciò provochi un rallentamento del tuo flusso di lavoro. La velocità con cui dovrebbero essere esattamente e la frequenza con cui dovresti eseguirli è aperta al dibattito (e dipende in gran parte dalla tecnologia che utilizzi e dal tuo flusso di lavoro), ma dovresti comunque mirare a renderli abbastanza veloci da non essere indesiderati interruzione.
3. I test unitari dovrebbero essere indipendenti dall'ordine di esecuzione. Se tutti i test superano, dovresti essere in grado di eseguirli in tutte le possibili permutazioni del loro ordine di esecuzione e continuare a passare tutti loro. In particolare, nessun test deve dipendere dall'esecuzione dopo un altro test.

Con questo in mente, torniamo alla tua domanda sulla derisione.
Quando si verifica il Repository stesso, sta prendendo in giro l'idea di aggiungere qualcosa ai punti sopra? Probabilmente no. Il repository dovrebbe essere il componente che comunica con il database e si desidera verificare che ciò avvenga correttamente. E probabilmente i test non sono così estesi che è difficile tenerli indipendenti e relativamente veloci.

Durante il test del resto della tua applicazione, diventa una storia diversa. Poiché i database sono generalmente molto validi per i contenuti persistenti, anche nei casi di test e i database non sono i componenti più veloci in circolazione, l'esperienza generale è che testare su un database reale rende più difficile mantenere tutti i test in modo rapido e indipendente.
Poiché i test del Repository ti danno la sicurezza che quel componente funzioni correttamente, il consiglio è quello di mozzare / simulare / falsificare negli altri test. In questi test, il tuo finto repository può controllare esattamente cosa viene restituito e può farlo direttamente dalla memoria.

Per arrotondare il tutto, è necessario anche un paio di test di integrazione / accettazione end-to-end per verificare che il comportamento degli stub / falsi / mock sia coerente con il comportamento dei componenti reali.

Test su un DB è molto semplice: usa le transazioni e il rollback dopo aver eseguito l'operazione e controllato il risultato. In alternativa, utilizzare un DB di test in cui si popola un set di dati di test prima di ogni esecuzione di test.

Il test delle unità non deve riguardare l'isolamento di ogni piccolo metodo: Martin Fowler descrive un'unità come classe e classi connesse quando parla di Agile. Quindi un DB non deve essere una singola istruzione di inserimento su un DB puramente vuoto (e non dovrebbe essere come vorrete verificare che funzioni con i dati esistenti che rompono i vincoli)

Se è necessario testare l'unità di ciascun metodo, il modo più semplice per farlo con un DB è quello di mettere l'SQL in stored procedure. Dopo tutto, ogni procedura è un metodo solitario. Quindi puoi testarli come qualsiasi altro metodo nelle tue classi di business logic: all'interno di una transazione, impostare alcuni dati (troncare, inserire), eseguire sproc, verificare il risultato tramite un select o altro codice di ritorno, rollback. Facile.