C'è un problema con la scrittura di un DAL in memoria per testare BLL / ViewModels?

Question

C'è un problema con la scrittura di un DAL in memoria per testare BLL / ViewModels?

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

1

La simulazione del DAL / Repository che ho passato a BLL / ViewModels a scopo di test non è molto diversa dalla creazione di un DAL in memoria. In questo momento sto usando un DAL in memoria in un nuovo progetto invece di prenderlo in giro e sta funzionando molto bene finora (anche più semplice di come configurare i mock che potrei dire).

Dato che non ho visto questo fatto negli esempi di libri / online ho pensato di chiederlo. C'è un problema con la scrittura di un DAL in memoria per testare BLL / ViewModels?

Sulla mia architettura tutti i componenti condividono una libreria comune con tutte le interfacce rilevanti. Le cose sono in ritardo, il che mi consente di scambiare qualsiasi componente con un'altra della stessa interfaccia.

architecture design-patterns

posta Manuel 28.02.2012 - 07:44

fonte

2 risposte

1

Non c'è assolutamente nulla di sbagliato nel test contro un DAL in memoria se ti rendi conto che è test di integrazione al contrario di test dell'unità .

Non appena i test BLL iniziano a fare affidamento sulla persistenza in memoria, stai veramente testando 2 cose: il DAL in memoria e il BLL. I tuoi test non sono più isolati e potrebbero rompersi per un numero molto maggiore di motivi. Ci può essere ancora un valore in questo tipo di test in quanto consentono di verificare che il sistema funzioni bene con una memoria persistente (relativamente) rappresentativa.

Tuttavia, l'unico modo per testare il tuo BLL in isolamento, in altre parole per valutare la correttezza atomica di base dei tuoi oggetti, rimane la presa in giro di qualsiasi dipendenza esterna.

risposta data 28.02.2012 - 14:48

fonte

Leggi altre domande sui tag architecture design-patterns

Si sta specializzando nel settore IT? [chiuso] Quando diventa obbligatorio registrarsi con il Bluetooth Special Interest Group (SIG)?

score 2 · Accepted Answer

Non c'è necessariamente qualcosa di intrinsecamente sbagliato quando si sceglie di usare un DB in memoria invece di prendere in giro le cose, ma ci sono alcuni compromessi. L'IMO principale è rappresentato dalle prestazioni, che possono o meno preoccupare per te, a seconda di quanti test hai e di quanti dati hai bisogno di configurare.

Nella mia azienda il nostro prodotto principale ha alcune migliaia di test, circa la metà dei quali sono integrati con il nostro DB. Il resto è tutto deriso. I test DB richiedono circa 3-4 minuti per essere eseguiti, mentre i test di simulazione richiedono circa 15 secondi. Ovviamente, un DB reale è molto più lento di un DB in memoria, ma anche i dati falsi sono più veloci, e se tu avessi l'obiettivo di poter eseguire un ciclo di prova + compilato in un minuto, potrebbe essere difficile colpisci quel bersaglio usando qualsiasi database Inoltre, se i tuoi test si connettono a un DB, potrebbe essere impossibile eseguirli in multithreading. Utilizziamo NCrunch durante lo sviluppo per eseguire la nostra suite in background utilizzando tutti i core disponibili, in modo che possiamo ricevere feedback mentre stiamo codificando.

Molto probabilmente i dati derisi richiederanno più codice in anticipo, e potrebbe richiedere troppo tempo se non si dispone di validi framework per l'assistenza nella generazione di dati fittizi. Quindi dovrai sempre considerare il rapporto costi / benefici.