Devo simulare il repository e l'unità di lavoro per i test unitari?

Question

Devo simulare il repository e l'unità di lavoro per i test unitari?

#1 da (4 voti)
#2 da (1 voti)

1

Ho letto questo articolo: link

Dato che questo articolo ha quasi 4 anni, non spero che nei commenti degli articoli la mia domanda verrà risolta e ho deciso di chiedercelo qui.

In questo articolo, l'autore crea un altro MockRepository e MockUnitOfWork classi e implementa i propri metodi per abbinare i metodi Repository e UnitOfWork . ma utilizza List invece di DataContext .

Se utilizzo questo approccio e in futuro cambierò la mia implementazione per Repository o UnitOfWork . Significa che devo modificare l'implementazione anche per MockRepository e MockUnitOfWork .

Sembra un po 'frustante per me. Sembra che sto testando MockRepository e MockUnitOfWork separatamente e Repository e UnitOfWork rimangono ancora non testati.

Come pensi?

unit-testing repository mocking unit-of-work

posta Dato Maisuradze 12.06.2017 - 08:36

fonte

2 risposte

1

L'autore sta usando un LINQ a SQL DataContext che non è così semplice da prendere in giro. Ci sono modi per deriderlo, ma puoi semplicemente aggirarlo e creare un'implementazione falsa di Repository e UnitOfWork da utilizzare nei tuoi test. Se fai il miglio supplementare e crei un mock valido per un DataContext , non dovresti creare mock per il tuo Repository e UnitOfWork .

risposta data 12.06.2017 - 09:18

fonte

Leggi altre domande sui tag unit-testing repository mocking unit-of-work

Un endpoint REST può iniziare con un ID risorsa? Come rendere più testabile la complessa logica di business con molte dipendenze?

score 4 · Accepted Answer

Se segui lo schema descritto nell'articolo, devi solo modificare MockRepository o MockUnitOfWork se la rispettiva interfaccia ( IRepository e IUnitOfWork ) cambia.

L'idea alla base di questo è che puoi testare unitamente tutte le altre parti della tua applicazione senza bisogno di accedere a un vero database (e senza il problema che la persistenza dei dati in un database appropriato ti dà durante il test).

Solo le classi Repository e UnitOfWork stesse (quelle che contengono la connessione al database effettivo) necessitano di un database reale per essere testate unitamente e se la loro implementazione è abbastanza semplice, puoi persino scegliere di rinviare il test di quelle classi fino all'integrazione o ai test end-to-end.