MockRepository vs Test Database per Test unità

Question

MockRepository vs Test Database per Test unità

#1 da (1 voti)

1

Prima di iniziare, questa domanda non è la stessa di questa .

Venendo da uno sfondo PHP , la mia esperienza è in CakePHP , che è un framework che supporta Unit Testing impostando un database di test locale , gestito per classi speciali chiamate fixtures (dati CRUD sul test db prima di ogni suite di test tramite codice).

Tuttavia, essendo nuovo in .NET framework, le esercitazioni intermedie suggeriscono l'uso del modello Unità di lavoro , per utilizzare un repository reale o un repository finto tramite interface .

Quando si tratta di test delle unità , non c'è molta differenza tra questi 2 modi di gestire l'operazione dei dati, ma il problema che ho riscontrato è stato quando si caricavano dati relazionali, poiché il repository reale utilizza il framework ORM mentre il repository simulato utilizza qualcosa di simile a un'implementazione dell'interfaccia List per conservare i dati in memoria e non è in grado di caricare in modo appassionato né caricare dati relazionali pigri.

Fino a questo punto vedo 2 possibili ragioni per le quali sono intervenuto su questo problema:

Il repository fittizio dovrebbe essere codificato in modo da poter ottenere in qualche modo dati relazionali.
Non dovrei verificare se il modello ha acquisito dati correlati, ma testare solo se il controller è stato in grado di acquisire il modello principale dal repository.

Mi piacerebbe sapere quale dei 2 sopra sarebbe (o se forse c'è un terzo ...) e i vantaggi / svantaggi del repository finto vs test db.

tdd unit-testing unit-of-work

posta Christopher Francisco 06.02.2015 - 15:43

fonte

1 risposta

Leggi altre domande sui tag tdd unit-testing unit-of-work

Singola istanza del servizio Windows che esegue query su più database Integrazione del database delle app Rails e Laravel

score 1 · Accepted Answer

Dato uno scenario, quando viene chiamato un metodo, i dati devono essere mantenuti in db e devono seguire i seguenti passi:

Imposta il simulatore db vuoto (lo chiami mock) e lo passi come dipendenza
chiama il metodo che stai testando
Verifica che i dati siano stati memorizzati nel simulatore

o

Imposta il simulatore db con dati predefiniti e passalo come dipendenza
chiama il metodo che stai testando
Verifica che il metodo funzioni correttamente sui dati recuperati dal simulatore

Puoi chiarire quale scenario hai problemi con i dati relazionali. È se persistito nel simulatore o recuperato da esso.

Se stai testando la logica che si verifica nel tuo livello dati, finirai testare il codice di test (configurazione fittizia specificata) e non il sistema reale - tali test devono essere evitati mentre portano nessun valore.

Ad esempio se si dispone di un trigger che aggiunge una voce di registro all'operazione di aggiornamento e si desidera scrivere il test che aggiorna un record e controlla la nuova voce di registro, non c'è modo di testare l'unità. Devi non fare affidamento su mock per farlo per te. Scrivere invece integrazioni / test funzionali contro il sistema reale.