Qual è lo scopo di testare repository falsi?

Question

Ho cercato di spingere la mia mentalità durante lo sviluppo a casa per essere più orientato verso TDD e un po 'DDD.

Una cosa che non capisco, però, è perché dovresti creare un repository falso per testarlo? Non ci ho mai pensato molto, ma sicuramente l'idea del test è di aiutare a disaccoppiare il codice (dandoti maggiore flessibilità), tagliare il codice necessario e ridurre il numero di bug.

Quindi qualcuno può riempire il mio cervello folle sul perché ad alcuni piace testare i repository falsi? Avrei pensato che testare su un vero database fosse un'alternativa molto migliore alla creazione di un database falso perché allora SAPI che funziona contro il tuo archivio di dati del mondo reale.

Answer 1

Il repository falso consente di testare solo il codice dell'applicazione.

Il repository falso significa che un test automatizzato può facilmente impostare uno stato noto nel repository.

Il repository falso sarà più veloce di molti ordini di grandezza rispetto a un database reale.

Il repository falso NON sostituisce i test di sistema che includeranno il tuo database.

Answer 2

A mio modo di vedere, ci sono due ragioni davvero grandi per cui si mette alla prova risorse false:

• Rende i test unitari più veloci quando si è simulati su I / O o database lenti. Questo potrebbe non sembrare nulla se hai una piccola suite di test ma quando sei in grado di testare +500 unità inizia a fare la differenza. In tale quantità, i test eseguiti sul database inizieranno a richiedere alcuni secondi. I programmatori sono pigri e vogliono che le cose vadano veloci, quindi se l'esecuzione di una suite di test richiede più di 10 secondi, non sarai più felice di fare TDD.
• Ti costringe a pensare alla progettazione del tuo codice per rendere più semplici le modifiche. Anche la progettazione per iniezione di contratto e di dipendenza diventa molto più semplice se hai implementato interfacce o classi astratte. Se fatto correttamente, tale design semplifica la conformità alle modifiche al codice.

L'unico inconveniente è quello ovvio:

• Come puoi essere sicuro che funzioni davvero?

... e questo è il test di integrazione .

Answer 3

Ho votato a favore della risposta di Giraffe, ma voglio aggiungere solo un paio di punti:

• Ogni sviluppatore può usare un finto / falso repository per la propria unità test senza interferire con il test eseguiti da altri sviluppatori sullo stesso progetto.

• Uso di un repository finto / falso locale rinforza l'utente di un dato strato di astrazione, che è buono pratica di progettazione.

Ad esempio, ho usato qualcosa di semplice come un HashMap per implementare una simulazione del livello di accesso ai dati. Ciò rende estremamente facile per ogni unit test verificare che esistano esattamente le condizioni necessarie per il suo scopo e verificare che siano state effettuate le chiamate giuste sul livello di accesso ai dati.