Devo simulare un servizio di dominio?

Question

Devo simulare un servizio di dominio?

#1 da (6 voti)
#2 da (0 voti)

1

Sto cercando di decidere se introdurre dei mock nei miei test sul modello di dominio isolati. Ho un metodo di classe simile a questo:

public Offer AssignOffer(OfferType offerType, IOfferValueCalculator valueCalculator) 
        { 
            DateTime dateExpiring = offerType.CalculateExpirationDate(); 
            int value = valueCalculator.CalculateValue(this, offerType); 
            var offer = new Offer(this, offerType, dateExpiring, value); 
            _assignedOffers.Add(offer); 
            NumberOfActiveOffers++; 
            return offer; 
        }

che ho preso da qui: link

Ora ho letto questo articolo: link e questo articolo: link . Entrambi sembrano suggerire che non dovrei prendere in giro OfferType (dato che è un oggetto valore). Comunque la mia domanda è: dovrei prendere in giro IOfferValueCalculator (un servizio di dominio)? IOfferValueCalculator non si trova nel livello più interno della cipolla, tuttavia si trova nel modello di dominio (il secondo livello più interno della cipolla).

Il motivo per cui lo chiedo è perché tutti questi articoli fanno riferimento in modo specifico a Entità e Oggetti valore (sconsigliamo di deriderli), tuttavia non fanno riferimento ai Servizi di dominio.

unit-testing c# domain-driven-design

posta w0051977 24.01.2018 - 23:49

fonte

2 risposte

0

IOfferValueCalculator does not sit in the innermost layer of the Onion

Probabilmente dovrebbe - o almeno essere trattato come tale. Se ho capito bene, il codice è tratto da una presentazione in cui l'oratore rifiuta un progetto anemico orientato ai servizi in un modello di dominio ricco. Potrebbero esserci ancora tracce del vecchio design nel codice "dopo". Che resti un post-refactoring di Services layer separato potrebbe non essere intenzionale.

should I be mocking IOfferValueCalculator (a Domain Service)?

Alcuni oggetti di dominio rari possono essere iniettati con dipendenze che parlano con mondo esterno, cioè i confini architettonici trasversali. Questo dovrebbe probabilmente essere evitato, ma se non può, questo è quando servono i mock. In ogni caso, dovresti prendere in giro la dipendenza, non l'oggetto dominio.
Il resto del tempo, anche se in un livello Domain-ish accanto a Dominio, I concorda con gli articoli che hai citato che i test di dominio isolati hanno no bisogno di mock.

risposta data 25.01.2018 - 09:30

fonte

Leggi altre domande sui tag unit-testing c# domain-driven-design

__init__ differiscono dagli attributi dell'oggetto Suggerimento Versione del servizio REST

score 6 · Accepted Answer

Should I mock a Domain Service?

Risposte brevi

Dipende.
Fornire duplicati di test che sostengono i servizi di dominio spesso essere una buona idea.
Fornire mock che sostengono i servizi di dominio può essere una buona idea.

Quanto segue avrà più senso se si ha familiarità con i diversi sapori dei duplicati di prova; Mock Are Stub è un punto di partenza accessibile.

Risposte più lunghe:

L'uso dei duplicati di prova è un compromesso. Ci sono dei rischi associati al fatto che il sistema in esame non sta parlando con un vero collaboratore, e ci sono dei benefici. Parte del nostro mestiere è capire il commercio che stiamo facendo.

Ci sono proprietà che vogliamo che i nostri test abbiano.

Vogliamo che i test siano veloci, in modo che eseguirli sia meno di una distrazione.
Vogliamo che i test siano isolati, in modo che possiamo eseguirli in parallelo e risparmiare ancora più tempo per l'orologio da parete.
Vogliamo che i test siano semplici: meno righe di codice nella suite di test significano meno bug nella suite di test
Vogliamo che i test siano comprensibili - vogliamo che la maggior parte del codice descriva il test , piuttosto che descrivere un mucchio di scaffold
Vogliamo che i test siano stabili - se non apportiamo alcuna modifica, una seconda esecuzione di un test dovrebbe sempre darci lo stesso risultato del primo
Vogliamo che i test siano accurati: un test non funzionante dovrebbe sempre indicare un errore.

Ma tutti questi sono solo troppi a meno che

I test richiamano la nostra attenzione sugli errori che facciamo.

Sostituire i veri collaboratori (che tendono ad essere disordinati) con i falsi collaboratori (che tendono ad essere semplici) aumenta la probabilità di perdere determinate categorie di errori; quindi è meglio essere sicuri che quando facciamo ciò, i benefici che otteniamo compensino i maggiori rischi.

Non ricaviamo quasi nessun ulteriore beneficio dal prendere in giro un valore. Oggetti di valore ben progettati sono già ben isolati, senza effetti collaterali e tendono ad esprimere la semantica di un test meglio di quanto farebbe un sostituto. Vivono interamente all'interno del nucleo funzionale della tua applicazione.

Se esegui la stessa matematica sulle entità, vedrai che non ha molto senso deridere un'entità neanche.

Con i servizi di dominio , tuttavia, i compromessi sembrano davvero interessanti. I servizi di dominio sono il meccanismo tramite il quale una parte incapsulata del modello di dominio comunica con i suoi collaboratori; quei collaboratori potrebbero essere altre parti dello stesso modello, oppure potrebbero essere più lontani.

Quando Evans descrisse i servizi di dominio nel blue book, inserì tra gli esempi motivanti che necessitavano di accedere ai servizi di applicazioni e infrastrutture - codice che vive al di fuori del limite di astrazione del modello di dominio. I servizi di dominio sono spesso proxy per comunicare gli effetti collaterali, che possono persino superare i limiti del processo.

Mock across architecturally significant boundaries, but not within those boundaries.

I servizi di dominio sono spesso proxy per il codice attraverso un limite architettonicamente significativo.

Quindi, se hai un servizio di dominio che è un'astrazione in memoria - Gli ordini devono accedere a un servizio di calcolo delle imposte in memoria, allora il test double non fornisce un beneficio marginale tanto quanto un test double che sta in per un servizio di dominio che ha bisogno di parlare con un database ....

In altre parole, ci sono molte cose diverse sotto il termine "servizio di dominio" e hanno diversi compromessi.

È molto più probabile che utilizzi un test double quando il comportamento effettivo del servizio è difficile da prevedere o difficile da limitare.

IOfferCalculator.CalculateValue is a simple method in this case - it does not connect to a database and it does not call any other methods.

Sembra che il vantaggio marginale dell'introduzione di un finto sia piccolo; quindi consiglierei di usare l'implementazione reale in questa circostanza.